Am 23.08.17 um 11:08 schrieb Herby VojÄÃk:
jtuchel wrote:
Herby,
as Esteban already said, UPSERT doesn't make any sense in an ORM. It
I don't know... I just create new object (with same "primary key") and register it (yes, I know I get an error - maybe I should be able to set the policy to "overwrite" and it would makes sense; or not?).
What I mean is that for an ORM, an object can only be new or old. It can only be sure an object is Old if either a) The ORM itself has loaded it from the database b) the user forcibly tells it that an object is old There is no maybe in an ORM's world, because the consequences of maybe can make the whole thing brittle. Maybe would make optimistic locking and other mechanisms obsolete.
either knows the object as one that has been read in this session or not. If not, it is new and needs to be inserted.
You could, of course, try and see what happens if you let Glorp's insert operation always issue an UPSERT. This is probably very easy to do and at first sight there isn't too much I could think of that could go wrong with it.
But I guess including a check for existence of an object as Esteban suggests isn't too bad from the performance and "safety" POV. not sure I understand how a Dictionary Mapping could help here....
Similarly to what was posted above: I can simply at:put: and I don't care if I created the new key-value pair or overwritten the old value (in cases where simply putting new object under a key is feasible, which is in this case).
Still don't understand. An object has its attributes that are used as its identification for the corresponding row in the DB (the primary key thereof). That is also true for objects that are the value of an Asscoiation. The Smalltalk Dictionary is translated to something that holds references to objects by their primary key (Haven't used Dict mappings yet, but I'd guess it's a link table). So I don't see how that would solve your problem an object's primary key is either known in a session or it isn't. If it is, the object is known to have existed in the database at read time, if not, it's assumed to be new. If it is assumed to be new, the DB provides a mechanism for avoiding damage by its Uniqueness constraint and the ORM can only rely on that. Joachim