Re: [Pharo-users] Glorp: Is there some way to do insert-or-update?

[herby]

On August 24, 2017 7:26:00 AM GMT+02:00, "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

Re: [Pharo-users] Glorp: Is there some way to do insert-or-update?

[jtuc...@objektfabrik.de]

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

Re: [Pharo-users] Glorp: Is there some way to do insert-or-update?

[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?).



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+unsubscr...@googlegroups.com
.
To post to this group, send email to glorp-gr...@googlegroups.com
.
Visit this group at https://groups.google.com/group/glorp-group.
For more options, visit https://groups.google.com/d/optout.

Re: [Pharo-users] Glorp: Is there some way to do insert-or-update?

[jtuchel]

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. 
>

[Pharo-users] Glorp: Is there some way to do insert-or-update?

[Herby 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.