On August 24, 2017 7:26:00 AM GMT+02:00, "jtuc...@objektfabrik.de" <jtuc...@objektfabrik.de> wrote: >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
Yes, this cannot be avoided. But in cases where I want to write over the item, I am not forced to choose between two different approaches and just use at:put:. So it IMO helps from client code PoV. >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
