Glorp: Is there some way to do insert-or-update?
Hello! Is there some way to do insert-or-update operation (that is, roughly, to be able to register an object with possibly existing primary key(s) and let it be written regardless? Thanks, Herby P.S.: Use case - I want to have log of USER-DEVICE pairing with last timestamp and 'enabled' field that would be set to false once push notification fails - but set to true once user actually logs from the device (again). I don't want to have many historical records, so I want to have USER+DEVICE to be a composed primary key. Which means it is inserted first time, but possibly updated later.
Herby, as Esteban already said, UPSERT doesn't make any sense in an ORM. It 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.... Joachim Am Dienstag, 22. August 2017 12:13:30 UTC+2 schrieb Herbert VojÄÃk:
Hello!
Is there some way to do insert-or-update operation (that is, roughly, to be able to register an object with possibly existing primary key(s) and let it be written regardless?
Thanks, Herby
P.S.: Use case - I want to have log of USER-DEVICE pairing with last timestamp and 'enabled' field that would be set to false once push notification fails - but set to true once user actually logs from the device (again). I don't want to have many historical records, so I want to have USER+DEVICE to be a composed primary key. Which means it is inserted first time, but possibly updated later.
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?).
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).
Joachim
Herby
Am Dienstag, 22. August 2017 12:13:30 UTC+2 schrieb Herbert VojÄÃk:
Hello!
Is there some way to do insert-or-update operation (that is, roughly, to be able to register an object with possibly existing primary key(s) and let it be written regardless?
Thanks, Herby
P.S.: Use case - I want to have log of USER-DEVICE pairing with last timestamp and 'enabled' field that would be set to false once push notification fails - but set to true once user actually logs from the device (again). I don't want to have many historical records, so I want to have USER+DEVICE to be a composed primary key. Which means it is inserted first time, but possibly updated later.
-- You received this message because you are subscribed to the Google Groups "glorp-group" group. To unsubscribe from this group and stop receiving emails from it, send an email to glorp-group+unsubscribe@googlegroups.com <mailto:glorp-group+unsubscribe@googlegroups.com>. To post to this group, send email to glorp-group@googlegroups.com <mailto:glorp-group@googlegroups.com>. Visit this group at https://groups.google.com/group/glorp-group. For more options, visit https://groups.google.com/d/optout.
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
On August 24, 2017 7:26:00 AM GMT+02:00, "jtuchel@objektfabrik.de" <jtuchel@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
participants (4)
-
Herby VojÄÃk -
herby＠mailbox.sk
-
jtuchel -
jtuchel＠objektfabrik.de