With the approach that I suggested, the two copies of the same NEW object will
be disconnected from each other and live their lives independently. So when one
of the contexts is committed and then another, you'll end up with 2 new rows in
the database. That will solve the immediate problem of faulting, but is this
the desired behavior?
Andrus
> On Nov 15, 2024, at 12:41 AM, Markus Reich <reich.mar...@gmail.com> wrote:
>
> Thank you for analyzing this case.
> The idea behind the local context was, that this is a dialog opened by the
> users where it's possible to create/change other objects and I don't want
> that a commit in the global context affects the local object.
>
> Meex
>
> Am Do., 14. Nov. 2024 um 20:21 Uhr schrieb Andrus Adamchik <
> aadamc...@gmail.com>:
>
>> Looking at the code, it appears that "localObject(..)" behavior for NEW
>> objects is incorrect. It creates a HOLLOW object, and as a result an
>> attempt is made to fetch it from the database on first access, resulting in
>> the exception. So formally, this is a bug (or rather a gap) in
>> localObject(..) logic. For NEW objects, it should probably do a full clone
>> of all values and set the state to NEW. I will open a bug report.
>>
>> And the workaround would be smth like this:
>>
>> T o1 = .. // initial new object
>> T o1Local = context.newObject(T.class);
>>
>> // manually copy data from "o1"
>> o1Local.setX(o1.getX());
>> o1Local.setY(o1.getY());
>> ...
>>
>> Having said that, what is a motivation for calling localObject(..) on a
>> new object?
>>
>> Andrus
>>
>>
>>> On Nov 14, 2024, at 10:36 AM, Markus Reich <reich.mar...@gmail.com>
>> wrote:
>>>
>>> found another case where no relationship is involved, but also the object
>>> is moved to a new local Context
>>>
>>> the error occurs then when trying to the readProperty id
>>>
>>> public String getId() {
>>>
>>> beforePropertyRead("id");
>>>
>>> return this.id;
>>>
>>> }
>>>
>>>
>>> id is defined as primary key and mandatory
>>>
>>>
>>> Am Do., 14. Nov. 2024 um 15:13 Uhr schrieb Andrus Adamchik <
>>> aadamc...@gmail.com>:
>>>
>>>> FaultFailureExceptions are usually caused by referential integrity
>>>> problems in DB. But this one is unusual as it references a TEMP ID
>> (i.e. an
>>>> uncommitted object). I don't think I've seen this flavor. Can you
>> provide
>>>> some more context around the error. I.e. what code leads to this.
>>>>
>>>> Andrus
>>>>
>>>>
>>>>> On Nov 14, 2024, at 9:07 AM, Markus Reich <reich.mar...@gmail.com>
>>>> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> in my production environment sometimes I get the following errors:
>>>>>
>>>>> FaultFailureException
>>>>>
>>>>> [v.4.2.1 Jun 14 2024 07:43:08] Error resolving fault, no matching row
>>>>> exists in the database for ObjectId:
>>>>> <ObjectId:Recipes,TEMP:-639058002>
>>>>>
>>>>>
>>>>> they are not specific to a certain object and I did get it
>>>>> reproducible to debug it :-/
>>>>>
>>>>>
>>>>> Maybe someone has some hints or tipps to get the root of evil?
>>>>>
>>>>>
>>>>> regards
>>>>>
>>>>> Meex
>>>>
>>>>
>>>
>>> --
>>> *Markus Reich*
>>> Waldweg 62
>>> 6393 St. Ulrich am Pillersee
>>> reich.mar...@gmail.com
>>
>>
>
> --
> *Markus Reich*
> Waldweg 62
> 6393 St. Ulrich am Pillersee
> reich.mar...@gmail.com
