Win a copy of The Business Blockchain this week in the Cloud forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

TopLink solution for an example

 
Adela Popescu
Greenhorn
Posts: 18
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello,

I hope somebody can help me. I have one database table which has as primary keys ID and VERSION. Other columns are VALID_FROM and a lot of other columns.
I need to have two classes, the Data class and DataHistory class. So I have also two persistence classes that both maps to this table. From the Data class I need the list of histories and the current history entry. This means I have a OneToManyMapping to the DataHistory class for the list of histories. For the current history I have a OneToOneMapping to the History class with setting the query for the max version for VALID_FROM <= current date.
The mapping for the current entry is:
OneToOneMapping oneToOneMapping = new OneToOneMapping();
oneToOneMapping .setAttributeName("_current");
oneToOneMapping .setReferenceClass(DataHistory.class));
oneToOneMapping .setForeignKeyFieldName("ID");
oneToOneMapping .setForeignKeyFieldName("VERSION");

d.oneToOneMapping (oneToOneMapping );

I receive errors that this mapping is not OK.
Do you know why??
Many thanks in advance,
Adela
 
Doug Gschwind
Ranch Hand
Posts: 44
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Adela,

I would have to see what you have in place for both the Data and the DataHistory descriptors in entirety to understand further. Instead, allow me to offer the following suggestions.

It seems clear that you have a need for both DataHistory and Data classes in your domain model. Seems also that your DataHistory class has two relationships of interest. One is a collection type to all of the Data instances that comprise the history in entirety. The other is the one to one relationship that represents the "current" Data instance for that DataHistory instance.

I would recommend a separation of concerns here and use two tables. If you had a DATA_HISTORY table, I can see the need for two columns, ID and VERSION, where the ID column is the lone primary key. The VERSION column can then be used for optimistic lock checking, but otherwise doesn't house any other business information.

If you then also had a DATA table, I can see the need for at least four columns there ID (primary key, orthogonal to DATA_HISTORY.ID), DATA_HISTORY_FK (points to DATA_HISTORY.ID), VALID_FROM (date not null), and VALID_TO (date). Probably no need for a VERSION column on this table since Data instances are immutable and a change to one really means adding a new instance to its history. That is if I understand your intent correctly.

In the descriptor for the DataHistory class, the one to many relationship that represents all of the Data instances can be set up to do some type of ordering and such. The "current" data instance, a one to one mapping, can be set up so that that mapping's selection criteria specifies where VALID_TO is null. You will of course have to keep that relationship up to date when a new Data instance is added to a DataHistory instance.

The descriptor for the Data class simply has the back pointing one to one relationship from the Data instance back to its owning DataHistory instance.

I think if you break those out that way, some of the complexity you described can be more easily managed.

-- Doug
 
Adela Popescu
Greenhorn
Posts: 18
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Doug,
Thank you for your detailed answer.
Regards,
Adela
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic