You're right! This makes no sense :-( so it was good that there is/was a
bug. I refactored my coding!
Andrus Adamchik <aadamc...@gmail.com> schrieb am Fr., 15. Nov. 2024, 20:11:
> 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
>
>
