Object Uniqueness
Added by Derek Spenser over 14 years ago
I just wanted to spur some conversation about what techniques are being used to ensure that a Wt::Dbo::ptr< C > is unique. There are some objects which naturally have a unique key which could be used. For example an employee could have an employee number which would uniquely identity that employee. There are those objects which don't naturally have a this type of convenience. Other ORM's I've seen use guid field or validate_uniqueness_of to accomplish this. So back to the original discussion, what techniques are being used in Wt to ensure two db objects are not the same objects?
Replies (3)
RE: Object Uniqueness - Added by Koen Deforche over 14 years ago
Hey Derrek,
Object uniqueness is based on the primary key, be it a surrogate key or a natural (possibly composite) primary key. Whenever an object needs to be loaded from the database (based on its id), it is first checked whether the object is in fact already present in the session. Wt requires that every mapped table has a primary key.
Object uniqueness is only checked within a single session.
Regards,
koen
RE: Object Uniqueness - Added by Derek Spenser over 14 years ago
Thanks Koen,
I think I need to be a little more detailed with my questions.
The id field generated by Wt certainly does uniquely identify a persisted object in relation to a database table. However, an issue arrises when a newly created transient object has the same state as a persisted object. If this newly created transient object, which has the same state as another persisted object, is committed to the database, then "twin" objects exist within the database. From the database viewpoint they are different records because they have different id values but all other fields are the same.
This is where a natural key would keep the two objects in different state. Going back to the previous example, an employee would have an employee number which uniquely identifies (in addition to the id field) that employee.
A composite key (the surrogate plus natrual keys effectively become this) also solves this issue, but I didn't see anything in the docs which allowed a composite key to be generated through multiple class fields. Ofcourse, a composite key could certainly be generated by creating the database schema manually.
Going back to the original post, there are some objects which don't have a natural key. In these intances, what have other programmers done to ensure that the database is not filled with objects which have the same state?
One answer to this could be: before adding(persisting) an object to the database, query the database by adding a WHERE clause for each field.
Another answer could be: send the object through a hash function which would generate a unique key based upon the object's state. The generated key would then be used as a pseudo natural key.
This is the question which I was trying to illicit some responses. Hopefully this is a little better explaination.
By the way Koen, I must say that I have enjoyed learning (the small amount that I have learned) Wt. I like the premise behind it. You have done a good job. Keep it up.
RE: Object Uniqueness - Added by Koen Deforche over 14 years ago
Hey Derek,
Composite keys are a new feature in 3.1.4: you can see a short explanation about them here: http://www.webtoolkit.eu/wt/doc/reference/html/structWt_1_1Dbo_1_1dbo__traits.html#fb62c3f28967b0b14b13360d47cd37dc
Wt::Dbo does not really provide any functionality related to the other cases (and I have also never experienced the need for such a kind of uniqueness check: if two users at the same time enter an account of the same data, then that is two distinct records: they should communicate better amongst themselves).
The hash function seems like a reasonable option. In the future we envision that the field() call will have an argument which contains options such as 'Unique' which translate to a matching database constraint.
We are fully aware of the many things that still can be improved in Wt and Wt::Dbo, so yes, we are going to keep up the good work !
Regards,
koen