Re: Glorp: Is there some way to do insert-or-update?

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

>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