Need a push in the right direction (parent-child object context and disappearing relationship)

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Need a push in the right direction (parent-child object context and disappearing relationship)

Lon Varscsak
I have an object (that’s new) in ObjectContextA that has a relationship to
another new object (same OC) which also has a reverse relationship.  I then
create a child of that OC (ObjectContactB) and grab a local version of the
first object.  At that time, the relationship object (and it’s reverse) is
there and all is good in the world.

The moment I touch the object (setting a simple property with
writeProperty) in the relationship the reverse relationship gets nulled
out.  Any thoughts as to why this might happen?

-Lon
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Need a push in the right direction (parent-child object context and disappearing relationship)

Lon Varscsak
I found the line that’s nulling it out…I just don’t understand at this deep level what’s going on.  Here’s the strack trace:



On Thu, Jul 13, 2017 at 10:43 AM, Lon Varscsak <[hidden email]> wrote:
I have an object (that’s new) in ObjectContextA that has a relationship to another new object (same OC) which also has a reverse relationship.  I then create a child of that OC (ObjectContactB) and grab a local version of the first object.  At that time, the relationship object (and it’s reverse) is there and all is good in the world.

The moment I touch the object (setting a simple property with writeProperty) in the relationship the reverse relationship gets nulled out.  Any thoughts as to why this might happen?

-Lon

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Need a push in the right direction (parent-child object context and disappearing relationship)

Andrus Adamchik
Unfortunately the mailing list strips attachments. Could you post the image elsewhere, like GoogleDrive or Dropbox?

Andrus

> On Jul 13, 2017, at 8:51 PM, Lon Varscsak <[hidden email]> wrote:
>
> I found the line that’s nulling it out…I just don’t understand at this deep level what’s going on.  Here’s the strack trace:
>
> On Thu, Jul 13, 2017 at 10:43 AM, Lon Varscsak <[hidden email]> wrote:
> I have an object (that’s new) in ObjectContextA that has a relationship to another new object (same OC) which also has a reverse relationship.  I then create a child of that OC (ObjectContactB) and grab a local version of the first object.  At that time, the relationship object (and it’s reverse) is there and all is good in the world.
>
> The moment I touch the object (setting a simple property with writeProperty) in the relationship the reverse relationship gets nulled out.  Any thoughts as to why this might happen?
>
> -Lon
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Need a push in the right direction (parent-child object context and disappearing relationship)

Lon Varscsak
Try this:

http://gofile.me/34oeM/YdPU7U4j1

On Mon, Jul 17, 2017 at 10:08 AM, Andrus Adamchik <[hidden email]>
wrote:

> Unfortunately the mailing list strips attachments. Could you post the
> image elsewhere, like GoogleDrive or Dropbox?
>
> Andrus
>
> > On Jul 13, 2017, at 8:51 PM, Lon Varscsak <[hidden email]>
> wrote:
> >
> > I found the line that’s nulling it out…I just don’t understand at this
> deep level what’s going on.  Here’s the strack trace:
> >
> > On Thu, Jul 13, 2017 at 10:43 AM, Lon Varscsak <[hidden email]>
> wrote:
> > I have an object (that’s new) in ObjectContextA that has a relationship
> to another new object (same OC) which also has a reverse relationship.  I
> then create a child of that OC (ObjectContactB) and grab a local version of
> the first object.  At that time, the relationship object (and it’s reverse)
> is there and all is good in the world.
> >
> > The moment I touch the object (setting a simple property with
> writeProperty) in the relationship the reverse relationship gets nulled
> out.  Any thoughts as to why this might happen?
> >
> > -Lon
> >
>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Need a push in the right direction (parent-child object context and disappearing relationship)

Lon Varscsak
Okay, that didn’t work.
https://www.dropbox.com/s/68hsculni16ucg3/Screen%20Shot%202017-07-13%20at%2010.50.24%20AM.png?dl=0

-Lon

On Mon, Jul 17, 2017 at 11:06 AM, Lon Varscsak <[hidden email]>
wrote:

> Try this:
>
> http://gofile.me/34oeM/YdPU7U4j1
>
> On Mon, Jul 17, 2017 at 10:08 AM, Andrus Adamchik <[hidden email]>
> wrote:
>
>> Unfortunately the mailing list strips attachments. Could you post the
>> image elsewhere, like GoogleDrive or Dropbox?
>>
>> Andrus
>>
>> > On Jul 13, 2017, at 8:51 PM, Lon Varscsak <[hidden email]>
>> wrote:
>> >
>> > I found the line that’s nulling it out…I just don’t understand at this
>> deep level what’s going on.  Here’s the strack trace:
>> >
>> > On Thu, Jul 13, 2017 at 10:43 AM, Lon Varscsak <[hidden email]>
>> wrote:
>> > I have an object (that’s new) in ObjectContextA that has a relationship
>> to another new object (same OC) which also has a reverse relationship.  I
>> then create a child of that OC (ObjectContactB) and grab a local version of
>> the first object.  At that time, the relationship object (and it’s reverse)
>> is there and all is good in the world.
>> >
>> > The moment I touch the object (setting a simple property with
>> writeProperty) in the relationship the reverse relationship gets nulled
>> out.  Any thoughts as to why this might happen?
>> >
>> > -Lon
>> >
>>
>>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Need a push in the right direction (parent-child object context and disappearing relationship)

Nikita Timofeev
Hi Lon,

I've tried to dig dipper into your case, and I can't repeat described
behavior, all I see is that toOne
relationship in object that moved to other context is faulted and
resolved on next access,
and no reverse relationships are affected. And that I assume is
expected behavior.

And even more I can't figure out case when line 194 in DataRowUtils can be hit.
May be you can provide some simple test case?

On Mon, Jul 17, 2017 at 9:14 PM, Lon Varscsak <[hidden email]> wrote:

> Okay, that didn’t work.
> https://www.dropbox.com/s/68hsculni16ucg3/Screen%20Shot%202017-07-13%20at%2010.50.24%20AM.png?dl=0
>
> -Lon
>
> On Mon, Jul 17, 2017 at 11:06 AM, Lon Varscsak <[hidden email]>
> wrote:
>
>> Try this:
>>
>> http://gofile.me/34oeM/YdPU7U4j1
>>
>> On Mon, Jul 17, 2017 at 10:08 AM, Andrus Adamchik <[hidden email]>
>> wrote:
>>
>>> Unfortunately the mailing list strips attachments. Could you post the
>>> image elsewhere, like GoogleDrive or Dropbox?
>>>
>>> Andrus
>>>
>>> > On Jul 13, 2017, at 8:51 PM, Lon Varscsak <[hidden email]>
>>> wrote:
>>> >
>>> > I found the line that’s nulling it out…I just don’t understand at this
>>> deep level what’s going on.  Here’s the strack trace:
>>> >
>>> > On Thu, Jul 13, 2017 at 10:43 AM, Lon Varscsak <[hidden email]>
>>> wrote:
>>> > I have an object (that’s new) in ObjectContextA that has a relationship
>>> to another new object (same OC) which also has a reverse relationship.  I
>>> then create a child of that OC (ObjectContactB) and grab a local version of
>>> the first object.  At that time, the relationship object (and it’s reverse)
>>> is there and all is good in the world.
>>> >
>>> > The moment I touch the object (setting a simple property with
>>> writeProperty) in the relationship the reverse relationship gets nulled
>>> out.  Any thoughts as to why this might happen?
>>> >
>>> > -Lon
>>> >
>>>
>>>
>>



--
Best regards,
Nikita Timofeev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Need a push in the right direction (parent-child object context and disappearing relationship)

Lon Varscsak
Okay, I’ll see if I can work up a test case.  Note:  This only happens if
the objects in question are new objects (not in the db).  When it tries to
find the “id” in DataRowUtils it comes back with nothing, so then it nulls
the reverse relationship out (even though at that point the reverse
relationship is in the child and has all of it’s values).

-Lon

On Wed, Jul 19, 2017 at 12:34 AM, Nikita Timofeev <[hidden email]
> wrote:

> Hi Lon,
>
> I've tried to dig dipper into your case, and I can't repeat described
> behavior, all I see is that toOne
> relationship in object that moved to other context is faulted and
> resolved on next access,
> and no reverse relationships are affected. And that I assume is
> expected behavior.
>
> And even more I can't figure out case when line 194 in DataRowUtils can be
> hit.
> May be you can provide some simple test case?
>
> On Mon, Jul 17, 2017 at 9:14 PM, Lon Varscsak <[hidden email]>
> wrote:
> > Okay, that didn’t work.
> > <a href="https://www.dropbox.com/s/68hsculni16ucg3/Screen%20Shot%">https://www.dropbox.com/s/68hsculni16ucg3/Screen%20Shot%
> 202017-07-13%20at%2010.50.24%20AM.png?dl=0
> >
> > -Lon
> >
> > On Mon, Jul 17, 2017 at 11:06 AM, Lon Varscsak <[hidden email]>
> > wrote:
> >
> >> Try this:
> >>
> >> http://gofile.me/34oeM/YdPU7U4j1
> >>
> >> On Mon, Jul 17, 2017 at 10:08 AM, Andrus Adamchik <
> [hidden email]>
> >> wrote:
> >>
> >>> Unfortunately the mailing list strips attachments. Could you post the
> >>> image elsewhere, like GoogleDrive or Dropbox?
> >>>
> >>> Andrus
> >>>
> >>> > On Jul 13, 2017, at 8:51 PM, Lon Varscsak <[hidden email]>
> >>> wrote:
> >>> >
> >>> > I found the line that’s nulling it out…I just don’t understand at
> this
> >>> deep level what’s going on.  Here’s the strack trace:
> >>> >
> >>> > On Thu, Jul 13, 2017 at 10:43 AM, Lon Varscsak <
> [hidden email]>
> >>> wrote:
> >>> > I have an object (that’s new) in ObjectContextA that has a
> relationship
> >>> to another new object (same OC) which also has a reverse
> relationship.  I
> >>> then create a child of that OC (ObjectContactB) and grab a local
> version of
> >>> the first object.  At that time, the relationship object (and it’s
> reverse)
> >>> is there and all is good in the world.
> >>> >
> >>> > The moment I touch the object (setting a simple property with
> >>> writeProperty) in the relationship the reverse relationship gets nulled
> >>> out.  Any thoughts as to why this might happen?
> >>> >
> >>> > -Lon
> >>> >
> >>>
> >>>
> >>
>
>
>
> --
> Best regards,
> Nikita Timofeev
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Need a push in the right direction (parent-child object context and disappearing relationship)

Lon Varscsak
I can also get it to throw this error:

Caused by: org.apache.cayenne.FaultFailureException: [v.4.1.M1-SNAPSHOT Jul
19 2017 19:49:41] Error resolving fault, no matching row exists in the
database for ObjectId: <ObjectId:OrderDetailSale, order_line_number=2,
order_number=55663878>

at org.apache.cayenne.BaseContext.prepareForAccess(BaseContext.java:365)

at org.apache.cayenne.CayenneDataObject.readProperty(
CayenneDataObject.java:174)

at
com.smarthealth.businesslogic.production.auto._OrderDetailSale.getPersonalizationDiscPercent(
_OrderDetailSale.java:316)

at
com.smarthealth.businesslogic.production.auto._OrderDetailSale.personalizationDiscPercent(
_OrderDetailSale.java:319)

at
com.smarthealth.businesslogic.production.BillingOrderDetailSales.personalizationDiscountAmount(
BillingOrderDetailSales.java:26)

at
com.smarthealth.businesslogic.production.BillingOrderDetailSales.extendedPrice(
BillingOrderDetailSales.java:30)

Where the OrderDetailSale object in question is new on an OrderHeader which
isn’t new.

-Lon

On Wed, Jul 19, 2017 at 1:23 PM, Lon Varscsak <[hidden email]>
wrote:

> Okay, I’ll see if I can work up a test case.  Note:  This only happens if
> the objects in question are new objects (not in the db).  When it tries to
> find the “id” in DataRowUtils it comes back with nothing, so then it nulls
> the reverse relationship out (even though at that point the reverse
> relationship is in the child and has all of it’s values).
>
> -Lon
>
> On Wed, Jul 19, 2017 at 12:34 AM, Nikita Timofeev <
> [hidden email]> wrote:
>
>> Hi Lon,
>>
>> I've tried to dig dipper into your case, and I can't repeat described
>> behavior, all I see is that toOne
>> relationship in object that moved to other context is faulted and
>> resolved on next access,
>> and no reverse relationships are affected. And that I assume is
>> expected behavior.
>>
>> And even more I can't figure out case when line 194 in DataRowUtils can
>> be hit.
>> May be you can provide some simple test case?
>>
>> On Mon, Jul 17, 2017 at 9:14 PM, Lon Varscsak <[hidden email]>
>> wrote:
>> > Okay, that didn’t work.
>> > https://www.dropbox.com/s/68hsculni16ucg3/Screen%20Shot%2020
>> 17-07-13%20at%2010.50.24%20AM.png?dl=0
>> >
>> > -Lon
>> >
>> > On Mon, Jul 17, 2017 at 11:06 AM, Lon Varscsak <[hidden email]>
>> > wrote:
>> >
>> >> Try this:
>> >>
>> >> http://gofile.me/34oeM/YdPU7U4j1
>> >>
>> >> On Mon, Jul 17, 2017 at 10:08 AM, Andrus Adamchik <
>> [hidden email]>
>> >> wrote:
>> >>
>> >>> Unfortunately the mailing list strips attachments. Could you post the
>> >>> image elsewhere, like GoogleDrive or Dropbox?
>> >>>
>> >>> Andrus
>> >>>
>> >>> > On Jul 13, 2017, at 8:51 PM, Lon Varscsak <[hidden email]>
>> >>> wrote:
>> >>> >
>> >>> > I found the line that’s nulling it out…I just don’t understand at
>> this
>> >>> deep level what’s going on.  Here’s the strack trace:
>> >>> >
>> >>> > On Thu, Jul 13, 2017 at 10:43 AM, Lon Varscsak <
>> [hidden email]>
>> >>> wrote:
>> >>> > I have an object (that’s new) in ObjectContextA that has a
>> relationship
>> >>> to another new object (same OC) which also has a reverse
>> relationship.  I
>> >>> then create a child of that OC (ObjectContactB) and grab a local
>> version of
>> >>> the first object.  At that time, the relationship object (and it’s
>> reverse)
>> >>> is there and all is good in the world.
>> >>> >
>> >>> > The moment I touch the object (setting a simple property with
>> >>> writeProperty) in the relationship the reverse relationship gets
>> nulled
>> >>> out.  Any thoughts as to why this might happen?
>> >>> >
>> >>> > -Lon
>> >>> >
>> >>>
>> >>>
>> >>
>>
>>
>>
>> --
>> Best regards,
>> Nikita Timofeev
>>
>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Need a push in the right direction (parent-child object context and disappearing relationship)

Lon Varscsak
Okay here’s a maven project that should work for you (it’s a wicket
application, but that shouldn’t matter…I think all the dependencies should
work) .

Here’s the file:
https://www.dropbox.com/s/7mhq8zz5zfqthdv/cayennebug.tar.gz?dl=0
Use this url after running:  http://localhost:8080/apps/cayennebug/

Here’s what’s happening.  On the main page I create an Order object and add
3 Payment objects to it.  This is in the “parent” context and is just in
the context, not in the db.  If you add a new Payment (link at bottom of
the first page) everything works fine, the new Payment object is created in
the child (inside ChildPage.java) added to the “localed” Order.  No
problems.  You’ll get returned to the HomePage and you will see your new
payment added.

If you EDIT one of the existing ones (1-3…maybe 4, but not sure) we local
the Order and the Payment (or grab the payment from the localed
Order…either way), then the moment you touch the Payment object (by
changing the amount) it clears it’s Order reverse relationship because it
sees that the “id” isn’t set (which it isn’t yet, this would technically
happen later on save in my real world application).  In this case you’ll
get a NPE because I’m logging out the Payment’s getOrder().something() and
getOrder() is now returning null.  You should be able to see that you’ll
reach the line of code that I sent in my previous email (in DataRowUtils).

So that leads to another problem.  If I have a proper order number (you can
uncomment the line in HomePage.java), when you setAmount it will now try to
retrieve the object from the database which will obviously return no
results and throws the exception in my previous email (“Error resolving
fault, no matching row exists in the database for ObjectId”).

This fails in 4.0.M5 and 4.1.M1-SNAPSHOT.  Any help would be greatly
appreciated.

Thanks,

Lon

On Wed, Jul 19, 2017 at 1:24 PM, Lon Varscsak <[hidden email]>
wrote:

> I can also get it to throw this error:
>
> Caused by: org.apache.cayenne.FaultFailureException: [v.4.1.M1-SNAPSHOT
> Jul 19 2017 19:49:41] Error resolving fault, no matching row exists in the
> database for ObjectId: <ObjectId:OrderDetailSale, order_line_number=2,
> order_number=55663878>
>
> at org.apache.cayenne.BaseContext.prepareForAccess(BaseContext.java:365)
>
> at org.apache.cayenne.CayenneDataObject.readProperty(CayenneDataObject
> .java:174)
>
> at com.smarthealth.businesslogic.production.auto._OrderDetailSale.
> getPersonalizationDiscPercent(_OrderDetailSale.java:316)
>
> at com.smarthealth.businesslogic.production.auto._OrderDetailSale.
> personalizationDiscPercent(_OrderDetailSale.java:319)
>
> at com.smarthealth.businesslogic.production.BillingOrderDetailSales.
> personalizationDiscountAmount(BillingOrderDetailSales.java:26)
>
> at com.smarthealth.businesslogic.production.BillingOrderDetailSales.
> extendedPrice(BillingOrderDetailSales.java:30)
>
> Where the OrderDetailSale object in question is new on an OrderHeader
> which isn’t new.
>
> -Lon
>
> On Wed, Jul 19, 2017 at 1:23 PM, Lon Varscsak <[hidden email]>
> wrote:
>
>> Okay, I’ll see if I can work up a test case.  Note:  This only happens if
>> the objects in question are new objects (not in the db).  When it tries to
>> find the “id” in DataRowUtils it comes back with nothing, so then it nulls
>> the reverse relationship out (even though at that point the reverse
>> relationship is in the child and has all of it’s values).
>>
>> -Lon
>>
>> On Wed, Jul 19, 2017 at 12:34 AM, Nikita Timofeev <
>> [hidden email]> wrote:
>>
>>> Hi Lon,
>>>
>>> I've tried to dig dipper into your case, and I can't repeat described
>>> behavior, all I see is that toOne
>>> relationship in object that moved to other context is faulted and
>>> resolved on next access,
>>> and no reverse relationships are affected. And that I assume is
>>> expected behavior.
>>>
>>> And even more I can't figure out case when line 194 in DataRowUtils can
>>> be hit.
>>> May be you can provide some simple test case?
>>>
>>> On Mon, Jul 17, 2017 at 9:14 PM, Lon Varscsak <[hidden email]>
>>> wrote:
>>> > Okay, that didn’t work.
>>> > https://www.dropbox.com/s/68hsculni16ucg3/Screen%20Shot%2020
>>> 17-07-13%20at%2010.50.24%20AM.png?dl=0
>>> >
>>> > -Lon
>>> >
>>> > On Mon, Jul 17, 2017 at 11:06 AM, Lon Varscsak <[hidden email]
>>> >
>>> > wrote:
>>> >
>>> >> Try this:
>>> >>
>>> >> http://gofile.me/34oeM/YdPU7U4j1
>>> >>
>>> >> On Mon, Jul 17, 2017 at 10:08 AM, Andrus Adamchik <
>>> [hidden email]>
>>> >> wrote:
>>> >>
>>> >>> Unfortunately the mailing list strips attachments. Could you post the
>>> >>> image elsewhere, like GoogleDrive or Dropbox?
>>> >>>
>>> >>> Andrus
>>> >>>
>>> >>> > On Jul 13, 2017, at 8:51 PM, Lon Varscsak <[hidden email]>
>>> >>> wrote:
>>> >>> >
>>> >>> > I found the line that’s nulling it out…I just don’t understand at
>>> this
>>> >>> deep level what’s going on.  Here’s the strack trace:
>>> >>> >
>>> >>> > On Thu, Jul 13, 2017 at 10:43 AM, Lon Varscsak <
>>> [hidden email]>
>>> >>> wrote:
>>> >>> > I have an object (that’s new) in ObjectContextA that has a
>>> relationship
>>> >>> to another new object (same OC) which also has a reverse
>>> relationship.  I
>>> >>> then create a child of that OC (ObjectContactB) and grab a local
>>> version of
>>> >>> the first object.  At that time, the relationship object (and it’s
>>> reverse)
>>> >>> is there and all is good in the world.
>>> >>> >
>>> >>> > The moment I touch the object (setting a simple property with
>>> >>> writeProperty) in the relationship the reverse relationship gets
>>> nulled
>>> >>> out.  Any thoughts as to why this might happen?
>>> >>> >
>>> >>> > -Lon
>>> >>> >
>>> >>>
>>> >>>
>>> >>
>>>
>>>
>>>
>>> --
>>> Best regards,
>>> Nikita Timofeev
>>>
>>
>>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Need a push in the right direction (parent-child object context and disappearing relationship)

Nikita Timofeev
Thanks for such a detailed example!

Short version of what happening: meaningful FK drives Cayenne crazy.
It just can't handle this particular case, so easiest solution is to
get rid of those and everything will be ok.

I've checked same case but without mapped FK and everything just
works, no relationships missing in parent or child context.

A little bit more details why this happening:

1. NPE - is a result of missing value for mapped FK. from the Cayenne
POV FK is in snapshot came from parent context but it's null so
Cayenne should set relationship to null or otherwise there will be
problems when merging object with data from DB. This is what happening
in DataRowUtils.
2. When you manually set orderNumber there is no NPE, but fault can't
be resolved because it is unknown by parent context where this object
has temp ObjectId and query goes to DB where no object exists (again,
this will not be the problem if Cayenne manages all your
relationships, it will solve temp ObjectId correctly)

And there can be even more cases when meaningful Fk (as well as Pk)
can fail, so it is pretty general recommendation to stay away from
those as much as you can.

On Thu, Jul 20, 2017 at 4:08 AM, Lon Varscsak <[hidden email]> wrote:

> Okay here’s a maven project that should work for you (it’s a wicket
> application, but that shouldn’t matter…I think all the dependencies should
> work) .
>
> Here’s the file:
> https://www.dropbox.com/s/7mhq8zz5zfqthdv/cayennebug.tar.gz?dl=0
> Use this url after running:  http://localhost:8080/apps/cayennebug/
>
> Here’s what’s happening.  On the main page I create an Order object and add
> 3 Payment objects to it.  This is in the “parent” context and is just in the
> context, not in the db.  If you add a new Payment (link at bottom of the
> first page) everything works fine, the new Payment object is created in the
> child (inside ChildPage.java) added to the “localed” Order.  No problems.
> You’ll get returned to the HomePage and you will see your new payment added.
>
> If you EDIT one of the existing ones (1-3…maybe 4, but not sure) we local
> the Order and the Payment (or grab the payment from the localed Order…either
> way), then the moment you touch the Payment object (by changing the amount)
> it clears it’s Order reverse relationship because it sees that the “id”
> isn’t set (which it isn’t yet, this would technically happen later on save
> in my real world application).  In this case you’ll get a NPE because I’m
> logging out the Payment’s getOrder().something() and getOrder() is now
> returning null.  You should be able to see that you’ll reach the line of
> code that I sent in my previous email (in DataRowUtils).
>
> So that leads to another problem.  If I have a proper order number (you can
> uncomment the line in HomePage.java), when you setAmount it will now try to
> retrieve the object from the database which will obviously return no results
> and throws the exception in my previous email (“Error resolving fault, no
> matching row exists in the database for ObjectId”).
>
> This fails in 4.0.M5 and 4.1.M1-SNAPSHOT.  Any help would be greatly
> appreciated.
>
> Thanks,
>
> Lon
>
> On Wed, Jul 19, 2017 at 1:24 PM, Lon Varscsak <[hidden email]>
> wrote:
>>
>> I can also get it to throw this error:
>>
>> Caused by: org.apache.cayenne.FaultFailureException: [v.4.1.M1-SNAPSHOT
>> Jul 19 2017 19:49:41] Error resolving fault, no matching row exists in the
>> database for ObjectId: <ObjectId:OrderDetailSale, order_line_number=2,
>> order_number=55663878>
>>
>> at org.apache.cayenne.BaseContext.prepareForAccess(BaseContext.java:365)
>>
>> at
>> org.apache.cayenne.CayenneDataObject.readProperty(CayenneDataObject.java:174)
>>
>> at
>> com.smarthealth.businesslogic.production.auto._OrderDetailSale.getPersonalizationDiscPercent(_OrderDetailSale.java:316)
>>
>> at
>> com.smarthealth.businesslogic.production.auto._OrderDetailSale.personalizationDiscPercent(_OrderDetailSale.java:319)
>>
>> at
>> com.smarthealth.businesslogic.production.BillingOrderDetailSales.personalizationDiscountAmount(BillingOrderDetailSales.java:26)
>>
>> at
>> com.smarthealth.businesslogic.production.BillingOrderDetailSales.extendedPrice(BillingOrderDetailSales.java:30)
>>
>>
>> Where the OrderDetailSale object in question is new on an OrderHeader
>> which isn’t new.
>>
>> -Lon
>>
>> On Wed, Jul 19, 2017 at 1:23 PM, Lon Varscsak <[hidden email]>
>> wrote:
>>>
>>> Okay, I’ll see if I can work up a test case.  Note:  This only happens if
>>> the objects in question are new objects (not in the db).  When it tries to
>>> find the “id” in DataRowUtils it comes back with nothing, so then it nulls
>>> the reverse relationship out (even though at that point the reverse
>>> relationship is in the child and has all of it’s values).
>>>
>>> -Lon
>>>
>>> On Wed, Jul 19, 2017 at 12:34 AM, Nikita Timofeev
>>> <[hidden email]> wrote:
>>>>
>>>> Hi Lon,
>>>>
>>>> I've tried to dig dipper into your case, and I can't repeat described
>>>> behavior, all I see is that toOne
>>>> relationship in object that moved to other context is faulted and
>>>> resolved on next access,
>>>> and no reverse relationships are affected. And that I assume is
>>>> expected behavior.
>>>>
>>>> And even more I can't figure out case when line 194 in DataRowUtils can
>>>> be hit.
>>>> May be you can provide some simple test case?
>>>>
>>>> On Mon, Jul 17, 2017 at 9:14 PM, Lon Varscsak <[hidden email]>
>>>> wrote:
>>>> > Okay, that didn’t work.
>>>> >
>>>> > https://www.dropbox.com/s/68hsculni16ucg3/Screen%20Shot%202017-07-13%20at%2010.50.24%20AM.png?dl=0
>>>> >
>>>> > -Lon
>>>> >
>>>> > On Mon, Jul 17, 2017 at 11:06 AM, Lon Varscsak
>>>> > <[hidden email]>
>>>> > wrote:
>>>> >
>>>> >> Try this:
>>>> >>
>>>> >> http://gofile.me/34oeM/YdPU7U4j1
>>>> >>
>>>> >> On Mon, Jul 17, 2017 at 10:08 AM, Andrus Adamchik
>>>> >> <[hidden email]>
>>>> >> wrote:
>>>> >>
>>>> >>> Unfortunately the mailing list strips attachments. Could you post
>>>> >>> the
>>>> >>> image elsewhere, like GoogleDrive or Dropbox?
>>>> >>>
>>>> >>> Andrus
>>>> >>>
>>>> >>> > On Jul 13, 2017, at 8:51 PM, Lon Varscsak <[hidden email]>
>>>> >>> wrote:
>>>> >>> >
>>>> >>> > I found the line that’s nulling it out…I just don’t understand at
>>>> >>> > this
>>>> >>> deep level what’s going on.  Here’s the strack trace:
>>>> >>> >
>>>> >>> > On Thu, Jul 13, 2017 at 10:43 AM, Lon Varscsak
>>>> >>> > <[hidden email]>
>>>> >>> wrote:
>>>> >>> > I have an object (that’s new) in ObjectContextA that has a
>>>> >>> > relationship
>>>> >>> to another new object (same OC) which also has a reverse
>>>> >>> relationship.  I
>>>> >>> then create a child of that OC (ObjectContactB) and grab a local
>>>> >>> version of
>>>> >>> the first object.  At that time, the relationship object (and it’s
>>>> >>> reverse)
>>>> >>> is there and all is good in the world.
>>>> >>> >
>>>> >>> > The moment I touch the object (setting a simple property with
>>>> >>> writeProperty) in the relationship the reverse relationship gets
>>>> >>> nulled
>>>> >>> out.  Any thoughts as to why this might happen?
>>>> >>> >
>>>> >>> > -Lon
>>>> >>> >
>>>> >>>
>>>> >>>
>>>> >>
>>>>
>>>>
>>>>
>>>> --
>>>> Best regards,
>>>> Nikita Timofeev
>>>
>>>
>>
>



--
Best regards,
Nikita Timofeev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Need a push in the right direction (parent-child object context and disappearing relationship)

Lon Varscsak
Ah crap. :)  I can’t really get rid of meaningful PKs (legacy system), but
I can remove the PKs from the ObjEntity of the FK objects (Payments doesn’t
need orderNumber and paymentNumber exposed).   At that does seem to work.
However, in Payments, I’d still need to assign the paymentNumber portion of
the PK…what’s the best approach here (it’s not auto-assigned).

Also, it seems like there could be a special case in this scenario when
localing objects from another OC (parent) that handles TEMP ObjectIds
differently.  There would never be a situation where you’d want to go back
to DB access for a TEMP object.

Thanks!

-Lon

On Thu, Jul 20, 2017 at 1:28 AM, Nikita Timofeev <[hidden email]>
wrote:

> Thanks for such a detailed example!
>
> Short version of what happening: meaningful FK drives Cayenne crazy.
> It just can't handle this particular case, so easiest solution is to
> get rid of those and everything will be ok.
>
> I've checked same case but without mapped FK and everything just
> works, no relationships missing in parent or child context.
>
> A little bit more details why this happening:
>
> 1. NPE - is a result of missing value for mapped FK. from the Cayenne
> POV FK is in snapshot came from parent context but it's null so
> Cayenne should set relationship to null or otherwise there will be
> problems when merging object with data from DB. This is what happening
> in DataRowUtils.
> 2. When you manually set orderNumber there is no NPE, but fault can't
> be resolved because it is unknown by parent context where this object
> has temp ObjectId and query goes to DB where no object exists (again,
> this will not be the problem if Cayenne manages all your
> relationships, it will solve temp ObjectId correctly)
>
> And there can be even more cases when meaningful Fk (as well as Pk)
> can fail, so it is pretty general recommendation to stay away from
> those as much as you can.
>
> On Thu, Jul 20, 2017 at 4:08 AM, Lon Varscsak <[hidden email]>
> wrote:
> > Okay here’s a maven project that should work for you (it’s a wicket
> > application, but that shouldn’t matter…I think all the dependencies
> should
> > work) .
> >
> > Here’s the file:
> > https://www.dropbox.com/s/7mhq8zz5zfqthdv/cayennebug.tar.gz?dl=0
> > Use this url after running:  http://localhost:8080/apps/cayennebug/
> >
> > Here’s what’s happening.  On the main page I create an Order object and
> add
> > 3 Payment objects to it.  This is in the “parent” context and is just in
> the
> > context, not in the db.  If you add a new Payment (link at bottom of the
> > first page) everything works fine, the new Payment object is created in
> the
> > child (inside ChildPage.java) added to the “localed” Order.  No problems.
> > You’ll get returned to the HomePage and you will see your new payment
> added.
> >
> > If you EDIT one of the existing ones (1-3…maybe 4, but not sure) we local
> > the Order and the Payment (or grab the payment from the localed
> Order…either
> > way), then the moment you touch the Payment object (by changing the
> amount)
> > it clears it’s Order reverse relationship because it sees that the “id”
> > isn’t set (which it isn’t yet, this would technically happen later on
> save
> > in my real world application).  In this case you’ll get a NPE because I’m
> > logging out the Payment’s getOrder().something() and getOrder() is now
> > returning null.  You should be able to see that you’ll reach the line of
> > code that I sent in my previous email (in DataRowUtils).
> >
> > So that leads to another problem.  If I have a proper order number (you
> can
> > uncomment the line in HomePage.java), when you setAmount it will now try
> to
> > retrieve the object from the database which will obviously return no
> results
> > and throws the exception in my previous email (“Error resolving fault, no
> > matching row exists in the database for ObjectId”).
> >
> > This fails in 4.0.M5 and 4.1.M1-SNAPSHOT.  Any help would be greatly
> > appreciated.
> >
> > Thanks,
> >
> > Lon
> >
> > On Wed, Jul 19, 2017 at 1:24 PM, Lon Varscsak <[hidden email]>
> > wrote:
> >>
> >> I can also get it to throw this error:
> >>
> >> Caused by: org.apache.cayenne.FaultFailureException: [v.4.1.M1-SNAPSHOT
> >> Jul 19 2017 19:49:41] Error resolving fault, no matching row exists in
> the
> >> database for ObjectId: <ObjectId:OrderDetailSale, order_line_number=2,
> >> order_number=55663878>
> >>
> >> at org.apache.cayenne.BaseContext.prepareForAccess(
> BaseContext.java:365)
> >>
> >> at
> >> org.apache.cayenne.CayenneDataObject.readProperty(
> CayenneDataObject.java:174)
> >>
> >> at
> >> com.smarthealth.businesslogic.production.auto._OrderDetailSale.
> getPersonalizationDiscPercent(_OrderDetailSale.java:316)
> >>
> >> at
> >> com.smarthealth.businesslogic.production.auto._OrderDetailSale.
> personalizationDiscPercent(_OrderDetailSale.java:319)
> >>
> >> at
> >> com.smarthealth.businesslogic.production.BillingOrderDetailSales.
> personalizationDiscountAmount(BillingOrderDetailSales.java:26)
> >>
> >> at
> >> com.smarthealth.businesslogic.production.BillingOrderDetailSales.
> extendedPrice(BillingOrderDetailSales.java:30)
> >>
> >>
> >> Where the OrderDetailSale object in question is new on an OrderHeader
> >> which isn’t new.
> >>
> >> -Lon
> >>
> >> On Wed, Jul 19, 2017 at 1:23 PM, Lon Varscsak <[hidden email]>
> >> wrote:
> >>>
> >>> Okay, I’ll see if I can work up a test case.  Note:  This only happens
> if
> >>> the objects in question are new objects (not in the db).  When it
> tries to
> >>> find the “id” in DataRowUtils it comes back with nothing, so then it
> nulls
> >>> the reverse relationship out (even though at that point the reverse
> >>> relationship is in the child and has all of it’s values).
> >>>
> >>> -Lon
> >>>
> >>> On Wed, Jul 19, 2017 at 12:34 AM, Nikita Timofeev
> >>> <[hidden email]> wrote:
> >>>>
> >>>> Hi Lon,
> >>>>
> >>>> I've tried to dig dipper into your case, and I can't repeat described
> >>>> behavior, all I see is that toOne
> >>>> relationship in object that moved to other context is faulted and
> >>>> resolved on next access,
> >>>> and no reverse relationships are affected. And that I assume is
> >>>> expected behavior.
> >>>>
> >>>> And even more I can't figure out case when line 194 in DataRowUtils
> can
> >>>> be hit.
> >>>> May be you can provide some simple test case?
> >>>>
> >>>> On Mon, Jul 17, 2017 at 9:14 PM, Lon Varscsak <[hidden email]
> >
> >>>> wrote:
> >>>> > Okay, that didn’t work.
> >>>> >
> >>>> > <a href="https://www.dropbox.com/s/68hsculni16ucg3/Screen%20Shot%">https://www.dropbox.com/s/68hsculni16ucg3/Screen%20Shot%
> 202017-07-13%20at%2010.50.24%20AM.png?dl=0
> >>>> >
> >>>> > -Lon
> >>>> >
> >>>> > On Mon, Jul 17, 2017 at 11:06 AM, Lon Varscsak
> >>>> > <[hidden email]>
> >>>> > wrote:
> >>>> >
> >>>> >> Try this:
> >>>> >>
> >>>> >> http://gofile.me/34oeM/YdPU7U4j1
> >>>> >>
> >>>> >> On Mon, Jul 17, 2017 at 10:08 AM, Andrus Adamchik
> >>>> >> <[hidden email]>
> >>>> >> wrote:
> >>>> >>
> >>>> >>> Unfortunately the mailing list strips attachments. Could you post
> >>>> >>> the
> >>>> >>> image elsewhere, like GoogleDrive or Dropbox?
> >>>> >>>
> >>>> >>> Andrus
> >>>> >>>
> >>>> >>> > On Jul 13, 2017, at 8:51 PM, Lon Varscsak <
> [hidden email]>
> >>>> >>> wrote:
> >>>> >>> >
> >>>> >>> > I found the line that’s nulling it out…I just don’t understand
> at
> >>>> >>> > this
> >>>> >>> deep level what’s going on.  Here’s the strack trace:
> >>>> >>> >
> >>>> >>> > On Thu, Jul 13, 2017 at 10:43 AM, Lon Varscsak
> >>>> >>> > <[hidden email]>
> >>>> >>> wrote:
> >>>> >>> > I have an object (that’s new) in ObjectContextA that has a
> >>>> >>> > relationship
> >>>> >>> to another new object (same OC) which also has a reverse
> >>>> >>> relationship.  I
> >>>> >>> then create a child of that OC (ObjectContactB) and grab a local
> >>>> >>> version of
> >>>> >>> the first object.  At that time, the relationship object (and it’s
> >>>> >>> reverse)
> >>>> >>> is there and all is good in the world.
> >>>> >>> >
> >>>> >>> > The moment I touch the object (setting a simple property with
> >>>> >>> writeProperty) in the relationship the reverse relationship gets
> >>>> >>> nulled
> >>>> >>> out.  Any thoughts as to why this might happen?
> >>>> >>> >
> >>>> >>> > -Lon
> >>>> >>> >
> >>>> >>>
> >>>> >>>
> >>>> >>
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> Best regards,
> >>>> Nikita Timofeev
> >>>
> >>>
> >>
> >
>
>
>
> --
> Best regards,
> Nikita Timofeev
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Need a push in the right direction (parent-child object context and disappearing relationship)

Lon Varscsak
Okay, I’ve gotten farther, but still have an issue.  I’ve removed the FK
IDs from my objects and if I don’t pre-assign PKs to them it’s all good.
But if I assign a PK as I go then I get:

org.apache.cayenne.CayenneRuntimeException: [v.4.1.M1-SNAPSHOT Jul 19 2017
19:49:41] Some parts of FK are missing in snapshot, relationship: Db
Relationship : toOne  (billing_order_detail_sales.order_line_number,
order_detail_sales.order_line_number)
(billing_order_detail_sales.order_number, order_detail_sales.order_number)

at org.apache.cayenne.map.DbRelationship.targetPkSnapshotWithSrcSnapshot(
DbRelationship.java:421)

at org.apache.cayenne.DataRow.createTargetObjectId(DataRow.java:128)

at org.apache.cayenne.access.DataRowUtils$2.visitToOne(DataRowUtils.java:184
)

at org.apache.cayenne.reflect.generic.DataObjectToOneProperty.visit(
DataObjectToOneProperty.java:97)

at org.apache.cayenne.reflect.PersistentDescriptor.visitProperties(
PersistentDescriptor.java:400)

at org.apache.cayenne.reflect.LazyClassDescriptorDecorator.visitProperties(
LazyClassDescriptorDecorator.java:174)

at org.apache.cayenne.access.DataRowUtils.forceMergeWithSnapshot(
DataRowUtils.java:136)

at org.apache.cayenne.access.ObjectStore.registerDiff(ObjectStore.java:182)

at org.apache.cayenne.access.ObjectStore.nodePropertyChanged(
ObjectStore.java:940)

at
org.apache.cayenne.util.ObjectContextGraphAction.handleSimplePropertyChange(
ObjectContextGraphAction.java:102)

at org.apache.cayenne.util.ObjectContextGraphAction.handlePropertyChange(
ObjectContextGraphAction.java:68)

at org.apache.cayenne.BaseContext.propertyChanged(BaseContext.java:460)

at org.apache.cayenne.CayenneDataObject.writeProperty(
CayenneDataObject.java:200)

at
com.smarthealth.businesslogic.production.auto._BillingOrderDetailSales.setPersonalizationLineAmount(
_BillingOrderDetailSales.java:102)

at
com.smarthealth.businesslogic.util.SHOrderController.calculatePersonalization(
SHOrderController.java:833)


So I’ve assigned one of the PKs (order_line_number), but order_number
doesn’t get assigned until the user clicks save.  So this partial state
seems to confuse it too.  I assume if I assign the order_number, then I’ll
get the previous error where it tries to fault from the DB.  How difficult
would it be to modify Cayenne to deal with these TEMP objects better?


-Lon

On Thu, Jul 20, 2017 at 10:58 AM, Lon Varscsak <[hidden email]>
wrote:

> Ah crap. :)  I can’t really get rid of meaningful PKs (legacy system), but
> I can remove the PKs from the ObjEntity of the FK objects (Payments doesn’t
> need orderNumber and paymentNumber exposed).   At that does seem to work.
> However, in Payments, I’d still need to assign the paymentNumber portion of
> the PK…what’s the best approach here (it’s not auto-assigned).
>
> Also, it seems like there could be a special case in this scenario when
> localing objects from another OC (parent) that handles TEMP ObjectIds
> differently.  There would never be a situation where you’d want to go back
> to DB access for a TEMP object.
>
> Thanks!
>
> -Lon
>
> On Thu, Jul 20, 2017 at 1:28 AM, Nikita Timofeev <
> [hidden email]> wrote:
>
>> Thanks for such a detailed example!
>>
>> Short version of what happening: meaningful FK drives Cayenne crazy.
>> It just can't handle this particular case, so easiest solution is to
>> get rid of those and everything will be ok.
>>
>> I've checked same case but without mapped FK and everything just
>> works, no relationships missing in parent or child context.
>>
>> A little bit more details why this happening:
>>
>> 1. NPE - is a result of missing value for mapped FK. from the Cayenne
>> POV FK is in snapshot came from parent context but it's null so
>> Cayenne should set relationship to null or otherwise there will be
>> problems when merging object with data from DB. This is what happening
>> in DataRowUtils.
>> 2. When you manually set orderNumber there is no NPE, but fault can't
>> be resolved because it is unknown by parent context where this object
>> has temp ObjectId and query goes to DB where no object exists (again,
>> this will not be the problem if Cayenne manages all your
>> relationships, it will solve temp ObjectId correctly)
>>
>> And there can be even more cases when meaningful Fk (as well as Pk)
>> can fail, so it is pretty general recommendation to stay away from
>> those as much as you can.
>>
>> On Thu, Jul 20, 2017 at 4:08 AM, Lon Varscsak <[hidden email]>
>> wrote:
>> > Okay here’s a maven project that should work for you (it’s a wicket
>> > application, but that shouldn’t matter…I think all the dependencies
>> should
>> > work) .
>> >
>> > Here’s the file:
>> > https://www.dropbox.com/s/7mhq8zz5zfqthdv/cayennebug.tar.gz?dl=0
>> > Use this url after running:  http://localhost:8080/apps/cayennebug/
>> >
>> > Here’s what’s happening.  On the main page I create an Order object and
>> add
>> > 3 Payment objects to it.  This is in the “parent” context and is just
>> in the
>> > context, not in the db.  If you add a new Payment (link at bottom of the
>> > first page) everything works fine, the new Payment object is created in
>> the
>> > child (inside ChildPage.java) added to the “localed” Order.  No
>> problems.
>> > You’ll get returned to the HomePage and you will see your new payment
>> added.
>> >
>> > If you EDIT one of the existing ones (1-3…maybe 4, but not sure) we
>> local
>> > the Order and the Payment (or grab the payment from the localed
>> Order…either
>> > way), then the moment you touch the Payment object (by changing the
>> amount)
>> > it clears it’s Order reverse relationship because it sees that the “id”
>> > isn’t set (which it isn’t yet, this would technically happen later on
>> save
>> > in my real world application).  In this case you’ll get a NPE because
>> I’m
>> > logging out the Payment’s getOrder().something() and getOrder() is now
>> > returning null.  You should be able to see that you’ll reach the line of
>> > code that I sent in my previous email (in DataRowUtils).
>> >
>> > So that leads to another problem.  If I have a proper order number (you
>> can
>> > uncomment the line in HomePage.java), when you setAmount it will now
>> try to
>> > retrieve the object from the database which will obviously return no
>> results
>> > and throws the exception in my previous email (“Error resolving fault,
>> no
>> > matching row exists in the database for ObjectId”).
>> >
>> > This fails in 4.0.M5 and 4.1.M1-SNAPSHOT.  Any help would be greatly
>> > appreciated.
>> >
>> > Thanks,
>> >
>> > Lon
>> >
>> > On Wed, Jul 19, 2017 at 1:24 PM, Lon Varscsak <[hidden email]>
>> > wrote:
>> >>
>> >> I can also get it to throw this error:
>> >>
>> >> Caused by: org.apache.cayenne.FaultFailureException:
>> [v.4.1.M1-SNAPSHOT
>> >> Jul 19 2017 19:49:41] Error resolving fault, no matching row exists in
>> the
>> >> database for ObjectId: <ObjectId:OrderDetailSale, order_line_number=2,
>> >> order_number=55663878>
>> >>
>> >> at org.apache.cayenne.BaseContext.prepareForAccess(BaseContext.
>> java:365)
>> >>
>> >> at
>> >> org.apache.cayenne.CayenneDataObject.readProperty(CayenneDat
>> aObject.java:174)
>> >>
>> >> at
>> >> com.smarthealth.businesslogic.production.auto._OrderDetailSa
>> le.getPersonalizationDiscPercent(_OrderDetailSale.java:316)
>> >>
>> >> at
>> >> com.smarthealth.businesslogic.production.auto._OrderDetailSa
>> le.personalizationDiscPercent(_OrderDetailSale.java:319)
>> >>
>> >> at
>> >> com.smarthealth.businesslogic.production.BillingOrderDetailS
>> ales.personalizationDiscountAmount(BillingOrderDetailSales.java:26)
>> >>
>> >> at
>> >> com.smarthealth.businesslogic.production.BillingOrderDetailS
>> ales.extendedPrice(BillingOrderDetailSales.java:30)
>> >>
>> >>
>> >> Where the OrderDetailSale object in question is new on an OrderHeader
>> >> which isn’t new.
>> >>
>> >> -Lon
>> >>
>> >> On Wed, Jul 19, 2017 at 1:23 PM, Lon Varscsak <[hidden email]>
>> >> wrote:
>> >>>
>> >>> Okay, I’ll see if I can work up a test case.  Note:  This only
>> happens if
>> >>> the objects in question are new objects (not in the db).  When it
>> tries to
>> >>> find the “id” in DataRowUtils it comes back with nothing, so then it
>> nulls
>> >>> the reverse relationship out (even though at that point the reverse
>> >>> relationship is in the child and has all of it’s values).
>> >>>
>> >>> -Lon
>> >>>
>> >>> On Wed, Jul 19, 2017 at 12:34 AM, Nikita Timofeev
>> >>> <[hidden email]> wrote:
>> >>>>
>> >>>> Hi Lon,
>> >>>>
>> >>>> I've tried to dig dipper into your case, and I can't repeat described
>> >>>> behavior, all I see is that toOne
>> >>>> relationship in object that moved to other context is faulted and
>> >>>> resolved on next access,
>> >>>> and no reverse relationships are affected. And that I assume is
>> >>>> expected behavior.
>> >>>>
>> >>>> And even more I can't figure out case when line 194 in DataRowUtils
>> can
>> >>>> be hit.
>> >>>> May be you can provide some simple test case?
>> >>>>
>> >>>> On Mon, Jul 17, 2017 at 9:14 PM, Lon Varscsak <
>> [hidden email]>
>> >>>> wrote:
>> >>>> > Okay, that didn’t work.
>> >>>> >
>> >>>> > https://www.dropbox.com/s/68hsculni16ucg3/Screen%20Shot%2020
>> 17-07-13%20at%2010.50.24%20AM.png?dl=0
>> >>>> >
>> >>>> > -Lon
>> >>>> >
>> >>>> > On Mon, Jul 17, 2017 at 11:06 AM, Lon Varscsak
>> >>>> > <[hidden email]>
>> >>>> > wrote:
>> >>>> >
>> >>>> >> Try this:
>> >>>> >>
>> >>>> >> http://gofile.me/34oeM/YdPU7U4j1
>> >>>> >>
>> >>>> >> On Mon, Jul 17, 2017 at 10:08 AM, Andrus Adamchik
>> >>>> >> <[hidden email]>
>> >>>> >> wrote:
>> >>>> >>
>> >>>> >>> Unfortunately the mailing list strips attachments. Could you post
>> >>>> >>> the
>> >>>> >>> image elsewhere, like GoogleDrive or Dropbox?
>> >>>> >>>
>> >>>> >>> Andrus
>> >>>> >>>
>> >>>> >>> > On Jul 13, 2017, at 8:51 PM, Lon Varscsak <
>> [hidden email]>
>> >>>> >>> wrote:
>> >>>> >>> >
>> >>>> >>> > I found the line that’s nulling it out…I just don’t understand
>> at
>> >>>> >>> > this
>> >>>> >>> deep level what’s going on.  Here’s the strack trace:
>> >>>> >>> >
>> >>>> >>> > On Thu, Jul 13, 2017 at 10:43 AM, Lon Varscsak
>> >>>> >>> > <[hidden email]>
>> >>>> >>> wrote:
>> >>>> >>> > I have an object (that’s new) in ObjectContextA that has a
>> >>>> >>> > relationship
>> >>>> >>> to another new object (same OC) which also has a reverse
>> >>>> >>> relationship.  I
>> >>>> >>> then create a child of that OC (ObjectContactB) and grab a local
>> >>>> >>> version of
>> >>>> >>> the first object.  At that time, the relationship object (and
>> it’s
>> >>>> >>> reverse)
>> >>>> >>> is there and all is good in the world.
>> >>>> >>> >
>> >>>> >>> > The moment I touch the object (setting a simple property with
>> >>>> >>> writeProperty) in the relationship the reverse relationship gets
>> >>>> >>> nulled
>> >>>> >>> out.  Any thoughts as to why this might happen?
>> >>>> >>> >
>> >>>> >>> > -Lon
>> >>>> >>> >
>> >>>> >>>
>> >>>> >>>
>> >>>> >>
>> >>>>
>> >>>>
>> >>>>
>> >>>> --
>> >>>> Best regards,
>> >>>> Nikita Timofeev
>> >>>
>> >>>
>> >>
>> >
>>
>>
>>
>> --
>> Best regards,
>> Nikita Timofeev
>>
>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Need a push in the right direction (parent-child object context and disappearing relationship)

Nikita Timofeev
Well, I'm afraid that proper fix will be really difficult, as it'll
need to deal with all possible cases how meaningful Pk/Fk and their
combination can interact, while keeping in mind current behavior of
unmapped Pk/Fk.
If we narrow for now it down to only Pk, things can be slightly better
(and may fit in scope of 4.1), as we can try to do proper
synchronization of meaningful Pk set manually and ObjectId internal
state, but still need to research this deeper.

On Fri, Jul 21, 2017 at 4:10 AM, Lon Varscsak <[hidden email]> wrote:

> Okay, I’ve gotten farther, but still have an issue.  I’ve removed the FK
> IDs from my objects and if I don’t pre-assign PKs to them it’s all good.
> But if I assign a PK as I go then I get:
>
> org.apache.cayenne.CayenneRuntimeException: [v.4.1.M1-SNAPSHOT Jul 19 2017
> 19:49:41] Some parts of FK are missing in snapshot, relationship: Db
> Relationship : toOne  (billing_order_detail_sales.order_line_number,
> order_detail_sales.order_line_number)
> (billing_order_detail_sales.order_number, order_detail_sales.order_number)
>
> at org.apache.cayenne.map.DbRelationship.targetPkSnapshotWithSrcSnapshot(
> DbRelationship.java:421)
>
> at org.apache.cayenne.DataRow.createTargetObjectId(DataRow.java:128)
>
> at org.apache.cayenne.access.DataRowUtils$2.visitToOne(DataRowUtils.java:184
> )
>
> at org.apache.cayenne.reflect.generic.DataObjectToOneProperty.visit(
> DataObjectToOneProperty.java:97)
>
> at org.apache.cayenne.reflect.PersistentDescriptor.visitProperties(
> PersistentDescriptor.java:400)
>
> at org.apache.cayenne.reflect.LazyClassDescriptorDecorator.visitProperties(
> LazyClassDescriptorDecorator.java:174)
>
> at org.apache.cayenne.access.DataRowUtils.forceMergeWithSnapshot(
> DataRowUtils.java:136)
>
> at org.apache.cayenne.access.ObjectStore.registerDiff(ObjectStore.java:182)
>
> at org.apache.cayenne.access.ObjectStore.nodePropertyChanged(
> ObjectStore.java:940)
>
> at
> org.apache.cayenne.util.ObjectContextGraphAction.handleSimplePropertyChange(
> ObjectContextGraphAction.java:102)
>
> at org.apache.cayenne.util.ObjectContextGraphAction.handlePropertyChange(
> ObjectContextGraphAction.java:68)
>
> at org.apache.cayenne.BaseContext.propertyChanged(BaseContext.java:460)
>
> at org.apache.cayenne.CayenneDataObject.writeProperty(
> CayenneDataObject.java:200)
>
> at
> com.smarthealth.businesslogic.production.auto._BillingOrderDetailSales.setPersonalizationLineAmount(
> _BillingOrderDetailSales.java:102)
>
> at
> com.smarthealth.businesslogic.util.SHOrderController.calculatePersonalization(
> SHOrderController.java:833)
>
>
> So I’ve assigned one of the PKs (order_line_number), but order_number
> doesn’t get assigned until the user clicks save.  So this partial state
> seems to confuse it too.  I assume if I assign the order_number, then I’ll
> get the previous error where it tries to fault from the DB.  How difficult
> would it be to modify Cayenne to deal with these TEMP objects better?
>
>
> -Lon
>
> On Thu, Jul 20, 2017 at 10:58 AM, Lon Varscsak <[hidden email]>
> wrote:
>
>> Ah crap. :)  I can’t really get rid of meaningful PKs (legacy system), but
>> I can remove the PKs from the ObjEntity of the FK objects (Payments doesn’t
>> need orderNumber and paymentNumber exposed).   At that does seem to work.
>> However, in Payments, I’d still need to assign the paymentNumber portion of
>> the PK…what’s the best approach here (it’s not auto-assigned).
>>
>> Also, it seems like there could be a special case in this scenario when
>> localing objects from another OC (parent) that handles TEMP ObjectIds
>> differently.  There would never be a situation where you’d want to go back
>> to DB access for a TEMP object.
>>
>> Thanks!
>>
>> -Lon
>>
>> On Thu, Jul 20, 2017 at 1:28 AM, Nikita Timofeev <
>> [hidden email]> wrote:
>>
>>> Thanks for such a detailed example!
>>>
>>> Short version of what happening: meaningful FK drives Cayenne crazy.
>>> It just can't handle this particular case, so easiest solution is to
>>> get rid of those and everything will be ok.
>>>
>>> I've checked same case but without mapped FK and everything just
>>> works, no relationships missing in parent or child context.
>>>
>>> A little bit more details why this happening:
>>>
>>> 1. NPE - is a result of missing value for mapped FK. from the Cayenne
>>> POV FK is in snapshot came from parent context but it's null so
>>> Cayenne should set relationship to null or otherwise there will be
>>> problems when merging object with data from DB. This is what happening
>>> in DataRowUtils.
>>> 2. When you manually set orderNumber there is no NPE, but fault can't
>>> be resolved because it is unknown by parent context where this object
>>> has temp ObjectId and query goes to DB where no object exists (again,
>>> this will not be the problem if Cayenne manages all your
>>> relationships, it will solve temp ObjectId correctly)
>>>
>>> And there can be even more cases when meaningful Fk (as well as Pk)
>>> can fail, so it is pretty general recommendation to stay away from
>>> those as much as you can.
>>>
>>> On Thu, Jul 20, 2017 at 4:08 AM, Lon Varscsak <[hidden email]>
>>> wrote:
>>> > Okay here’s a maven project that should work for you (it’s a wicket
>>> > application, but that shouldn’t matter…I think all the dependencies
>>> should
>>> > work) .
>>> >
>>> > Here’s the file:
>>> > https://www.dropbox.com/s/7mhq8zz5zfqthdv/cayennebug.tar.gz?dl=0
>>> > Use this url after running:  http://localhost:8080/apps/cayennebug/
>>> >
>>> > Here’s what’s happening.  On the main page I create an Order object and
>>> add
>>> > 3 Payment objects to it.  This is in the “parent” context and is just
>>> in the
>>> > context, not in the db.  If you add a new Payment (link at bottom of the
>>> > first page) everything works fine, the new Payment object is created in
>>> the
>>> > child (inside ChildPage.java) added to the “localed” Order.  No
>>> problems.
>>> > You’ll get returned to the HomePage and you will see your new payment
>>> added.
>>> >
>>> > If you EDIT one of the existing ones (1-3…maybe 4, but not sure) we
>>> local
>>> > the Order and the Payment (or grab the payment from the localed
>>> Order…either
>>> > way), then the moment you touch the Payment object (by changing the
>>> amount)
>>> > it clears it’s Order reverse relationship because it sees that the “id”
>>> > isn’t set (which it isn’t yet, this would technically happen later on
>>> save
>>> > in my real world application).  In this case you’ll get a NPE because
>>> I’m
>>> > logging out the Payment’s getOrder().something() and getOrder() is now
>>> > returning null.  You should be able to see that you’ll reach the line of
>>> > code that I sent in my previous email (in DataRowUtils).
>>> >
>>> > So that leads to another problem.  If I have a proper order number (you
>>> can
>>> > uncomment the line in HomePage.java), when you setAmount it will now
>>> try to
>>> > retrieve the object from the database which will obviously return no
>>> results
>>> > and throws the exception in my previous email (“Error resolving fault,
>>> no
>>> > matching row exists in the database for ObjectId”).
>>> >
>>> > This fails in 4.0.M5 and 4.1.M1-SNAPSHOT.  Any help would be greatly
>>> > appreciated.
>>> >
>>> > Thanks,
>>> >
>>> > Lon
>>> >
>>> > On Wed, Jul 19, 2017 at 1:24 PM, Lon Varscsak <[hidden email]>
>>> > wrote:
>>> >>
>>> >> I can also get it to throw this error:
>>> >>
>>> >> Caused by: org.apache.cayenne.FaultFailureException:
>>> [v.4.1.M1-SNAPSHOT
>>> >> Jul 19 2017 19:49:41] Error resolving fault, no matching row exists in
>>> the
>>> >> database for ObjectId: <ObjectId:OrderDetailSale, order_line_number=2,
>>> >> order_number=55663878>
>>> >>
>>> >> at org.apache.cayenne.BaseContext.prepareForAccess(BaseContext.
>>> java:365)
>>> >>
>>> >> at
>>> >> org.apache.cayenne.CayenneDataObject.readProperty(CayenneDat
>>> aObject.java:174)
>>> >>
>>> >> at
>>> >> com.smarthealth.businesslogic.production.auto._OrderDetailSa
>>> le.getPersonalizationDiscPercent(_OrderDetailSale.java:316)
>>> >>
>>> >> at
>>> >> com.smarthealth.businesslogic.production.auto._OrderDetailSa
>>> le.personalizationDiscPercent(_OrderDetailSale.java:319)
>>> >>
>>> >> at
>>> >> com.smarthealth.businesslogic.production.BillingOrderDetailS
>>> ales.personalizationDiscountAmount(BillingOrderDetailSales.java:26)
>>> >>
>>> >> at
>>> >> com.smarthealth.businesslogic.production.BillingOrderDetailS
>>> ales.extendedPrice(BillingOrderDetailSales.java:30)
>>> >>
>>> >>
>>> >> Where the OrderDetailSale object in question is new on an OrderHeader
>>> >> which isn’t new.
>>> >>
>>> >> -Lon
>>> >>
>>> >> On Wed, Jul 19, 2017 at 1:23 PM, Lon Varscsak <[hidden email]>
>>> >> wrote:
>>> >>>
>>> >>> Okay, I’ll see if I can work up a test case.  Note:  This only
>>> happens if
>>> >>> the objects in question are new objects (not in the db).  When it
>>> tries to
>>> >>> find the “id” in DataRowUtils it comes back with nothing, so then it
>>> nulls
>>> >>> the reverse relationship out (even though at that point the reverse
>>> >>> relationship is in the child and has all of it’s values).
>>> >>>
>>> >>> -Lon
>>> >>>
>>> >>> On Wed, Jul 19, 2017 at 12:34 AM, Nikita Timofeev
>>> >>> <[hidden email]> wrote:
>>> >>>>
>>> >>>> Hi Lon,
>>> >>>>
>>> >>>> I've tried to dig dipper into your case, and I can't repeat described
>>> >>>> behavior, all I see is that toOne
>>> >>>> relationship in object that moved to other context is faulted and
>>> >>>> resolved on next access,
>>> >>>> and no reverse relationships are affected. And that I assume is
>>> >>>> expected behavior.
>>> >>>>
>>> >>>> And even more I can't figure out case when line 194 in DataRowUtils
>>> can
>>> >>>> be hit.
>>> >>>> May be you can provide some simple test case?
>>> >>>>
>>> >>>> On Mon, Jul 17, 2017 at 9:14 PM, Lon Varscsak <
>>> [hidden email]>
>>> >>>> wrote:
>>> >>>> > Okay, that didn’t work.
>>> >>>> >
>>> >>>> > https://www.dropbox.com/s/68hsculni16ucg3/Screen%20Shot%2020
>>> 17-07-13%20at%2010.50.24%20AM.png?dl=0
>>> >>>> >
>>> >>>> > -Lon
>>> >>>> >
>>> >>>> > On Mon, Jul 17, 2017 at 11:06 AM, Lon Varscsak
>>> >>>> > <[hidden email]>
>>> >>>> > wrote:
>>> >>>> >
>>> >>>> >> Try this:
>>> >>>> >>
>>> >>>> >> http://gofile.me/34oeM/YdPU7U4j1
>>> >>>> >>
>>> >>>> >> On Mon, Jul 17, 2017 at 10:08 AM, Andrus Adamchik
>>> >>>> >> <[hidden email]>
>>> >>>> >> wrote:
>>> >>>> >>
>>> >>>> >>> Unfortunately the mailing list strips attachments. Could you post
>>> >>>> >>> the
>>> >>>> >>> image elsewhere, like GoogleDrive or Dropbox?
>>> >>>> >>>
>>> >>>> >>> Andrus
>>> >>>> >>>
>>> >>>> >>> > On Jul 13, 2017, at 8:51 PM, Lon Varscsak <
>>> [hidden email]>
>>> >>>> >>> wrote:
>>> >>>> >>> >
>>> >>>> >>> > I found the line that’s nulling it out…I just don’t understand
>>> at
>>> >>>> >>> > this
>>> >>>> >>> deep level what’s going on.  Here’s the strack trace:
>>> >>>> >>> >
>>> >>>> >>> > On Thu, Jul 13, 2017 at 10:43 AM, Lon Varscsak
>>> >>>> >>> > <[hidden email]>
>>> >>>> >>> wrote:
>>> >>>> >>> > I have an object (that’s new) in ObjectContextA that has a
>>> >>>> >>> > relationship
>>> >>>> >>> to another new object (same OC) which also has a reverse
>>> >>>> >>> relationship.  I
>>> >>>> >>> then create a child of that OC (ObjectContactB) and grab a local
>>> >>>> >>> version of
>>> >>>> >>> the first object.  At that time, the relationship object (and
>>> it’s
>>> >>>> >>> reverse)
>>> >>>> >>> is there and all is good in the world.
>>> >>>> >>> >
>>> >>>> >>> > The moment I touch the object (setting a simple property with
>>> >>>> >>> writeProperty) in the relationship the reverse relationship gets
>>> >>>> >>> nulled
>>> >>>> >>> out.  Any thoughts as to why this might happen?
>>> >>>> >>> >
>>> >>>> >>> > -Lon
>>> >>>> >>> >
>>> >>>> >>>
>>> >>>> >>>
>>> >>>> >>
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>> --
>>> >>>> Best regards,
>>> >>>> Nikita Timofeev
>>> >>>
>>> >>>
>>> >>
>>> >
>>>
>>>
>>>
>>> --
>>> Best regards,
>>> Nikita Timofeev
>>>
>>
>>



--
Best regards,
Nikita Timofeev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Need a push in the right direction (parent-child object context and disappearing relationship)

Lon Varscsak
Just to make sure we’re on the same page, when I local the object(s) into
an OC, all of the data and relationships are perfectly fine.  It’s just
that once I access (by setting a property) one of the objects the reverse
relationships either get nulled out or I get that missing object
exception.  It seems like the initial part is doing all the right stuff…but
something later is going awry.

-Lon

On Fri, Jul 21, 2017 at 2:06 AM, Nikita Timofeev <[hidden email]>
wrote:

> Well, I'm afraid that proper fix will be really difficult, as it'll
> need to deal with all possible cases how meaningful Pk/Fk and their
> combination can interact, while keeping in mind current behavior of
> unmapped Pk/Fk.
> If we narrow for now it down to only Pk, things can be slightly better
> (and may fit in scope of 4.1), as we can try to do proper
> synchronization of meaningful Pk set manually and ObjectId internal
> state, but still need to research this deeper.
>
> On Fri, Jul 21, 2017 at 4:10 AM, Lon Varscsak <[hidden email]>
> wrote:
> > Okay, I’ve gotten farther, but still have an issue.  I’ve removed the FK
> > IDs from my objects and if I don’t pre-assign PKs to them it’s all good.
> > But if I assign a PK as I go then I get:
> >
> > org.apache.cayenne.CayenneRuntimeException: [v.4.1.M1-SNAPSHOT Jul 19
> 2017
> > 19:49:41] Some parts of FK are missing in snapshot, relationship: Db
> > Relationship : toOne  (billing_order_detail_sales.order_line_number,
> > order_detail_sales.order_line_number)
> > (billing_order_detail_sales.order_number, order_detail_sales.order_
> number)
> >
> > at org.apache.cayenne.map.DbRelationship.targetPkSnapshotWithSrcSnapsho
> t(
> > DbRelationship.java:421)
> >
> > at org.apache.cayenne.DataRow.createTargetObjectId(DataRow.java:128)
> >
> > at org.apache.cayenne.access.DataRowUtils$2.visitToOne(
> DataRowUtils.java:184
> > )
> >
> > at org.apache.cayenne.reflect.generic.DataObjectToOneProperty.visit(
> > DataObjectToOneProperty.java:97)
> >
> > at org.apache.cayenne.reflect.PersistentDescriptor.visitProperties(
> > PersistentDescriptor.java:400)
> >
> > at org.apache.cayenne.reflect.LazyClassDescriptorDecorator.
> visitProperties(
> > LazyClassDescriptorDecorator.java:174)
> >
> > at org.apache.cayenne.access.DataRowUtils.forceMergeWithSnapshot(
> > DataRowUtils.java:136)
> >
> > at org.apache.cayenne.access.ObjectStore.registerDiff(
> ObjectStore.java:182)
> >
> > at org.apache.cayenne.access.ObjectStore.nodePropertyChanged(
> > ObjectStore.java:940)
> >
> > at
> > org.apache.cayenne.util.ObjectContextGraphAction.
> handleSimplePropertyChange(
> > ObjectContextGraphAction.java:102)
> >
> > at org.apache.cayenne.util.ObjectContextGraphAction.
> handlePropertyChange(
> > ObjectContextGraphAction.java:68)
> >
> > at org.apache.cayenne.BaseContext.propertyChanged(BaseContext.java:460)
> >
> > at org.apache.cayenne.CayenneDataObject.writeProperty(
> > CayenneDataObject.java:200)
> >
> > at
> > com.smarthealth.businesslogic.production.auto._BillingOrderDetailSales.
> setPersonalizationLineAmount(
> > _BillingOrderDetailSales.java:102)
> >
> > at
> > com.smarthealth.businesslogic.util.SHOrderController.
> calculatePersonalization(
> > SHOrderController.java:833)
> >
> >
> > So I’ve assigned one of the PKs (order_line_number), but order_number
> > doesn’t get assigned until the user clicks save.  So this partial state
> > seems to confuse it too.  I assume if I assign the order_number, then
> I’ll
> > get the previous error where it tries to fault from the DB.  How
> difficult
> > would it be to modify Cayenne to deal with these TEMP objects better?
> >
> >
> > -Lon
> >
> > On Thu, Jul 20, 2017 at 10:58 AM, Lon Varscsak <[hidden email]>
> > wrote:
> >
> >> Ah crap. :)  I can’t really get rid of meaningful PKs (legacy system),
> but
> >> I can remove the PKs from the ObjEntity of the FK objects (Payments
> doesn’t
> >> need orderNumber and paymentNumber exposed).   At that does seem to
> work.
> >> However, in Payments, I’d still need to assign the paymentNumber
> portion of
> >> the PK…what’s the best approach here (it’s not auto-assigned).
> >>
> >> Also, it seems like there could be a special case in this scenario when
> >> localing objects from another OC (parent) that handles TEMP ObjectIds
> >> differently.  There would never be a situation where you’d want to go
> back
> >> to DB access for a TEMP object.
> >>
> >> Thanks!
> >>
> >> -Lon
> >>
> >> On Thu, Jul 20, 2017 at 1:28 AM, Nikita Timofeev <
> >> [hidden email]> wrote:
> >>
> >>> Thanks for such a detailed example!
> >>>
> >>> Short version of what happening: meaningful FK drives Cayenne crazy.
> >>> It just can't handle this particular case, so easiest solution is to
> >>> get rid of those and everything will be ok.
> >>>
> >>> I've checked same case but without mapped FK and everything just
> >>> works, no relationships missing in parent or child context.
> >>>
> >>> A little bit more details why this happening:
> >>>
> >>> 1. NPE - is a result of missing value for mapped FK. from the Cayenne
> >>> POV FK is in snapshot came from parent context but it's null so
> >>> Cayenne should set relationship to null or otherwise there will be
> >>> problems when merging object with data from DB. This is what happening
> >>> in DataRowUtils.
> >>> 2. When you manually set orderNumber there is no NPE, but fault can't
> >>> be resolved because it is unknown by parent context where this object
> >>> has temp ObjectId and query goes to DB where no object exists (again,
> >>> this will not be the problem if Cayenne manages all your
> >>> relationships, it will solve temp ObjectId correctly)
> >>>
> >>> And there can be even more cases when meaningful Fk (as well as Pk)
> >>> can fail, so it is pretty general recommendation to stay away from
> >>> those as much as you can.
> >>>
> >>> On Thu, Jul 20, 2017 at 4:08 AM, Lon Varscsak <[hidden email]>
> >>> wrote:
> >>> > Okay here’s a maven project that should work for you (it’s a wicket
> >>> > application, but that shouldn’t matter…I think all the dependencies
> >>> should
> >>> > work) .
> >>> >
> >>> > Here’s the file:
> >>> > https://www.dropbox.com/s/7mhq8zz5zfqthdv/cayennebug.tar.gz?dl=0
> >>> > Use this url after running:  http://localhost:8080/apps/cayennebug/
> >>> >
> >>> > Here’s what’s happening.  On the main page I create an Order object
> and
> >>> add
> >>> > 3 Payment objects to it.  This is in the “parent” context and is just
> >>> in the
> >>> > context, not in the db.  If you add a new Payment (link at bottom of
> the
> >>> > first page) everything works fine, the new Payment object is created
> in
> >>> the
> >>> > child (inside ChildPage.java) added to the “localed” Order.  No
> >>> problems.
> >>> > You’ll get returned to the HomePage and you will see your new payment
> >>> added.
> >>> >
> >>> > If you EDIT one of the existing ones (1-3…maybe 4, but not sure) we
> >>> local
> >>> > the Order and the Payment (or grab the payment from the localed
> >>> Order…either
> >>> > way), then the moment you touch the Payment object (by changing the
> >>> amount)
> >>> > it clears it’s Order reverse relationship because it sees that the
> “id”
> >>> > isn’t set (which it isn’t yet, this would technically happen later on
> >>> save
> >>> > in my real world application).  In this case you’ll get a NPE because
> >>> I’m
> >>> > logging out the Payment’s getOrder().something() and getOrder() is
> now
> >>> > returning null.  You should be able to see that you’ll reach the
> line of
> >>> > code that I sent in my previous email (in DataRowUtils).
> >>> >
> >>> > So that leads to another problem.  If I have a proper order number
> (you
> >>> can
> >>> > uncomment the line in HomePage.java), when you setAmount it will now
> >>> try to
> >>> > retrieve the object from the database which will obviously return no
> >>> results
> >>> > and throws the exception in my previous email (“Error resolving
> fault,
> >>> no
> >>> > matching row exists in the database for ObjectId”).
> >>> >
> >>> > This fails in 4.0.M5 and 4.1.M1-SNAPSHOT.  Any help would be greatly
> >>> > appreciated.
> >>> >
> >>> > Thanks,
> >>> >
> >>> > Lon
> >>> >
> >>> > On Wed, Jul 19, 2017 at 1:24 PM, Lon Varscsak <
> [hidden email]>
> >>> > wrote:
> >>> >>
> >>> >> I can also get it to throw this error:
> >>> >>
> >>> >> Caused by: org.apache.cayenne.FaultFailureException:
> >>> [v.4.1.M1-SNAPSHOT
> >>> >> Jul 19 2017 19:49:41] Error resolving fault, no matching row exists
> in
> >>> the
> >>> >> database for ObjectId: <ObjectId:OrderDetailSale,
> order_line_number=2,
> >>> >> order_number=55663878>
> >>> >>
> >>> >> at org.apache.cayenne.BaseContext.prepareForAccess(BaseContext.
> >>> java:365)
> >>> >>
> >>> >> at
> >>> >> org.apache.cayenne.CayenneDataObject.readProperty(CayenneDat
> >>> aObject.java:174)
> >>> >>
> >>> >> at
> >>> >> com.smarthealth.businesslogic.production.auto._OrderDetailSa
> >>> le.getPersonalizationDiscPercent(_OrderDetailSale.java:316)
> >>> >>
> >>> >> at
> >>> >> com.smarthealth.businesslogic.production.auto._OrderDetailSa
> >>> le.personalizationDiscPercent(_OrderDetailSale.java:319)
> >>> >>
> >>> >> at
> >>> >> com.smarthealth.businesslogic.production.BillingOrderDetailS
> >>> ales.personalizationDiscountAmount(BillingOrderDetailSales.java:26)
> >>> >>
> >>> >> at
> >>> >> com.smarthealth.businesslogic.production.BillingOrderDetailS
> >>> ales.extendedPrice(BillingOrderDetailSales.java:30)
> >>> >>
> >>> >>
> >>> >> Where the OrderDetailSale object in question is new on an
> OrderHeader
> >>> >> which isn’t new.
> >>> >>
> >>> >> -Lon
> >>> >>
> >>> >> On Wed, Jul 19, 2017 at 1:23 PM, Lon Varscsak <
> [hidden email]>
> >>> >> wrote:
> >>> >>>
> >>> >>> Okay, I’ll see if I can work up a test case.  Note:  This only
> >>> happens if
> >>> >>> the objects in question are new objects (not in the db).  When it
> >>> tries to
> >>> >>> find the “id” in DataRowUtils it comes back with nothing, so then
> it
> >>> nulls
> >>> >>> the reverse relationship out (even though at that point the reverse
> >>> >>> relationship is in the child and has all of it’s values).
> >>> >>>
> >>> >>> -Lon
> >>> >>>
> >>> >>> On Wed, Jul 19, 2017 at 12:34 AM, Nikita Timofeev
> >>> >>> <[hidden email]> wrote:
> >>> >>>>
> >>> >>>> Hi Lon,
> >>> >>>>
> >>> >>>> I've tried to dig dipper into your case, and I can't repeat
> described
> >>> >>>> behavior, all I see is that toOne
> >>> >>>> relationship in object that moved to other context is faulted and
> >>> >>>> resolved on next access,
> >>> >>>> and no reverse relationships are affected. And that I assume is
> >>> >>>> expected behavior.
> >>> >>>>
> >>> >>>> And even more I can't figure out case when line 194 in
> DataRowUtils
> >>> can
> >>> >>>> be hit.
> >>> >>>> May be you can provide some simple test case?
> >>> >>>>
> >>> >>>> On Mon, Jul 17, 2017 at 9:14 PM, Lon Varscsak <
> >>> [hidden email]>
> >>> >>>> wrote:
> >>> >>>> > Okay, that didn’t work.
> >>> >>>> >
> >>> >>>> > https://www.dropbox.com/s/68hsculni16ucg3/Screen%20Shot%2020
> >>> 17-07-13%20at%2010.50.24%20AM.png?dl=0
> >>> >>>> >
> >>> >>>> > -Lon
> >>> >>>> >
> >>> >>>> > On Mon, Jul 17, 2017 at 11:06 AM, Lon Varscsak
> >>> >>>> > <[hidden email]>
> >>> >>>> > wrote:
> >>> >>>> >
> >>> >>>> >> Try this:
> >>> >>>> >>
> >>> >>>> >> http://gofile.me/34oeM/YdPU7U4j1
> >>> >>>> >>
> >>> >>>> >> On Mon, Jul 17, 2017 at 10:08 AM, Andrus Adamchik
> >>> >>>> >> <[hidden email]>
> >>> >>>> >> wrote:
> >>> >>>> >>
> >>> >>>> >>> Unfortunately the mailing list strips attachments. Could you
> post
> >>> >>>> >>> the
> >>> >>>> >>> image elsewhere, like GoogleDrive or Dropbox?
> >>> >>>> >>>
> >>> >>>> >>> Andrus
> >>> >>>> >>>
> >>> >>>> >>> > On Jul 13, 2017, at 8:51 PM, Lon Varscsak <
> >>> [hidden email]>
> >>> >>>> >>> wrote:
> >>> >>>> >>> >
> >>> >>>> >>> > I found the line that’s nulling it out…I just don’t
> understand
> >>> at
> >>> >>>> >>> > this
> >>> >>>> >>> deep level what’s going on.  Here’s the strack trace:
> >>> >>>> >>> >
> >>> >>>> >>> > On Thu, Jul 13, 2017 at 10:43 AM, Lon Varscsak
> >>> >>>> >>> > <[hidden email]>
> >>> >>>> >>> wrote:
> >>> >>>> >>> > I have an object (that’s new) in ObjectContextA that has a
> >>> >>>> >>> > relationship
> >>> >>>> >>> to another new object (same OC) which also has a reverse
> >>> >>>> >>> relationship.  I
> >>> >>>> >>> then create a child of that OC (ObjectContactB) and grab a
> local
> >>> >>>> >>> version of
> >>> >>>> >>> the first object.  At that time, the relationship object (and
> >>> it’s
> >>> >>>> >>> reverse)
> >>> >>>> >>> is there and all is good in the world.
> >>> >>>> >>> >
> >>> >>>> >>> > The moment I touch the object (setting a simple property
> with
> >>> >>>> >>> writeProperty) in the relationship the reverse relationship
> gets
> >>> >>>> >>> nulled
> >>> >>>> >>> out.  Any thoughts as to why this might happen?
> >>> >>>> >>> >
> >>> >>>> >>> > -Lon
> >>> >>>> >>> >
> >>> >>>> >>>
> >>> >>>> >>>
> >>> >>>> >>
> >>> >>>>
> >>> >>>>
> >>> >>>>
> >>> >>>> --
> >>> >>>> Best regards,
> >>> >>>> Nikita Timofeev
> >>> >>>
> >>> >>>
> >>> >>
> >>> >
> >>>
> >>>
> >>>
> >>> --
> >>> Best regards,
> >>> Nikita Timofeev
> >>>
> >>
> >>
>
>
>
> --
> Best regards,
> Nikita Timofeev
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Need a push in the right direction (parent-child object context and disappearing relationship)

Nikita Timofeev
Not quite so, localObject() will always return hollow object without
any values inside it. When you read something out of it all data will
be fetched from parent context so it will be there as expected.
But when you try to set something ... well that's where all this
problems come from.


On Tue, Jul 25, 2017 at 6:41 PM, Lon Varscsak <[hidden email]> wrote:

> Just to make sure we’re on the same page, when I local the object(s) into
> an OC, all of the data and relationships are perfectly fine. It’s just
> that once I access (by setting a property) one of the objects the reverse
> relationships either get nulled out or I get that missing object
> exception.  It seems like the initial part is doing all the right stuff…but
> something later is going awry.
>
> -Lon
>
> On Fri, Jul 21, 2017 at 2:06 AM, Nikita Timofeev <[hidden email]>
> wrote:
>
>> Well, I'm afraid that proper fix will be really difficult, as it'll
>> need to deal with all possible cases how meaningful Pk/Fk and their
>> combination can interact, while keeping in mind current behavior of
>> unmapped Pk/Fk.
>> If we narrow for now it down to only Pk, things can be slightly better
>> (and may fit in scope of 4.1), as we can try to do proper
>> synchronization of meaningful Pk set manually and ObjectId internal
>> state, but still need to research this deeper.
>>
>> On Fri, Jul 21, 2017 at 4:10 AM, Lon Varscsak <[hidden email]>
>> wrote:
>> > Okay, I’ve gotten farther, but still have an issue.  I’ve removed the FK
>> > IDs from my objects and if I don’t pre-assign PKs to them it’s all good.
>> > But if I assign a PK as I go then I get:
>> >
>> > org.apache.cayenne.CayenneRuntimeException: [v.4.1.M1-SNAPSHOT Jul 19
>> 2017
>> > 19:49:41] Some parts of FK are missing in snapshot, relationship: Db
>> > Relationship : toOne  (billing_order_detail_sales.order_line_number,
>> > order_detail_sales.order_line_number)
>> > (billing_order_detail_sales.order_number, order_detail_sales.order_
>> number)
>> >
>> > at org.apache.cayenne.map.DbRelationship.targetPkSnapshotWithSrcSnapsho
>> t(
>> > DbRelationship.java:421)
>> >
>> > at org.apache.cayenne.DataRow.createTargetObjectId(DataRow.java:128)
>> >
>> > at org.apache.cayenne.access.DataRowUtils$2.visitToOne(
>> DataRowUtils.java:184
>> > )
>> >
>> > at org.apache.cayenne.reflect.generic.DataObjectToOneProperty.visit(
>> > DataObjectToOneProperty.java:97)
>> >
>> > at org.apache.cayenne.reflect.PersistentDescriptor.visitProperties(
>> > PersistentDescriptor.java:400)
>> >
>> > at org.apache.cayenne.reflect.LazyClassDescriptorDecorator.
>> visitProperties(
>> > LazyClassDescriptorDecorator.java:174)
>> >
>> > at org.apache.cayenne.access.DataRowUtils.forceMergeWithSnapshot(
>> > DataRowUtils.java:136)
>> >
>> > at org.apache.cayenne.access.ObjectStore.registerDiff(
>> ObjectStore.java:182)
>> >
>> > at org.apache.cayenne.access.ObjectStore.nodePropertyChanged(
>> > ObjectStore.java:940)
>> >
>> > at
>> > org.apache.cayenne.util.ObjectContextGraphAction.
>> handleSimplePropertyChange(
>> > ObjectContextGraphAction.java:102)
>> >
>> > at org.apache.cayenne.util.ObjectContextGraphAction.
>> handlePropertyChange(
>> > ObjectContextGraphAction.java:68)
>> >
>> > at org.apache.cayenne.BaseContext.propertyChanged(BaseContext.java:460)
>> >
>> > at org.apache.cayenne.CayenneDataObject.writeProperty(
>> > CayenneDataObject.java:200)
>> >
>> > at
>> > com.smarthealth.businesslogic.production.auto._BillingOrderDetailSales.
>> setPersonalizationLineAmount(
>> > _BillingOrderDetailSales.java:102)
>> >
>> > at
>> > com.smarthealth.businesslogic.util.SHOrderController.
>> calculatePersonalization(
>> > SHOrderController.java:833)
>> >
>> >
>> > So I’ve assigned one of the PKs (order_line_number), but order_number
>> > doesn’t get assigned until the user clicks save.  So this partial state
>> > seems to confuse it too.  I assume if I assign the order_number, then
>> I’ll
>> > get the previous error where it tries to fault from the DB.  How
>> difficult
>> > would it be to modify Cayenne to deal with these TEMP objects better?
>> >
>> >
>> > -Lon
>> >
>> > On Thu, Jul 20, 2017 at 10:58 AM, Lon Varscsak <[hidden email]>
>> > wrote:
>> >
>> >> Ah crap. :)  I can’t really get rid of meaningful PKs (legacy system),
>> but
>> >> I can remove the PKs from the ObjEntity of the FK objects (Payments
>> doesn’t
>> >> need orderNumber and paymentNumber exposed).   At that does seem to
>> work.
>> >> However, in Payments, I’d still need to assign the paymentNumber
>> portion of
>> >> the PK…what’s the best approach here (it’s not auto-assigned).
>> >>
>> >> Also, it seems like there could be a special case in this scenario when
>> >> localing objects from another OC (parent) that handles TEMP ObjectIds
>> >> differently.  There would never be a situation where you’d want to go
>> back
>> >> to DB access for a TEMP object.
>> >>
>> >> Thanks!
>> >>
>> >> -Lon
>> >>
>> >> On Thu, Jul 20, 2017 at 1:28 AM, Nikita Timofeev <
>> >> [hidden email]> wrote:
>> >>
>> >>> Thanks for such a detailed example!
>> >>>
>> >>> Short version of what happening: meaningful FK drives Cayenne crazy.
>> >>> It just can't handle this particular case, so easiest solution is to
>> >>> get rid of those and everything will be ok.
>> >>>
>> >>> I've checked same case but without mapped FK and everything just
>> >>> works, no relationships missing in parent or child context.
>> >>>
>> >>> A little bit more details why this happening:
>> >>>
>> >>> 1. NPE - is a result of missing value for mapped FK. from the Cayenne
>> >>> POV FK is in snapshot came from parent context but it's null so
>> >>> Cayenne should set relationship to null or otherwise there will be
>> >>> problems when merging object with data from DB. This is what happening
>> >>> in DataRowUtils.
>> >>> 2. When you manually set orderNumber there is no NPE, but fault can't
>> >>> be resolved because it is unknown by parent context where this object
>> >>> has temp ObjectId and query goes to DB where no object exists (again,
>> >>> this will not be the problem if Cayenne manages all your
>> >>> relationships, it will solve temp ObjectId correctly)
>> >>>
>> >>> And there can be even more cases when meaningful Fk (as well as Pk)
>> >>> can fail, so it is pretty general recommendation to stay away from
>> >>> those as much as you can.
>> >>>
>> >>> On Thu, Jul 20, 2017 at 4:08 AM, Lon Varscsak <[hidden email]>
>> >>> wrote:
>> >>> > Okay here’s a maven project that should work for you (it’s a wicket
>> >>> > application, but that shouldn’t matter…I think all the dependencies
>> >>> should
>> >>> > work) .
>> >>> >
>> >>> > Here’s the file:
>> >>> > https://www.dropbox.com/s/7mhq8zz5zfqthdv/cayennebug.tar.gz?dl=0
>> >>> > Use this url after running:  http://localhost:8080/apps/cayennebug/
>> >>> >
>> >>> > Here’s what’s happening.  On the main page I create an Order object
>> and
>> >>> add
>> >>> > 3 Payment objects to it.  This is in the “parent” context and is just
>> >>> in the
>> >>> > context, not in the db.  If you add a new Payment (link at bottom of
>> the
>> >>> > first page) everything works fine, the new Payment object is created
>> in
>> >>> the
>> >>> > child (inside ChildPage.java) added to the “localed” Order.  No
>> >>> problems.
>> >>> > You’ll get returned to the HomePage and you will see your new payment
>> >>> added.
>> >>> >
>> >>> > If you EDIT one of the existing ones (1-3…maybe 4, but not sure) we
>> >>> local
>> >>> > the Order and the Payment (or grab the payment from the localed
>> >>> Order…either
>> >>> > way), then the moment you touch the Payment object (by changing the
>> >>> amount)
>> >>> > it clears it’s Order reverse relationship because it sees that the
>> “id”
>> >>> > isn’t set (which it isn’t yet, this would technically happen later on
>> >>> save
>> >>> > in my real world application).  In this case you’ll get a NPE because
>> >>> I’m
>> >>> > logging out the Payment’s getOrder().something() and getOrder() is
>> now
>> >>> > returning null.  You should be able to see that you’ll reach the
>> line of
>> >>> > code that I sent in my previous email (in DataRowUtils).
>> >>> >
>> >>> > So that leads to another problem.  If I have a proper order number
>> (you
>> >>> can
>> >>> > uncomment the line in HomePage.java), when you setAmount it will now
>> >>> try to
>> >>> > retrieve the object from the database which will obviously return no
>> >>> results
>> >>> > and throws the exception in my previous email (“Error resolving
>> fault,
>> >>> no
>> >>> > matching row exists in the database for ObjectId”).
>> >>> >
>> >>> > This fails in 4.0.M5 and 4.1.M1-SNAPSHOT.  Any help would be greatly
>> >>> > appreciated.
>> >>> >
>> >>> > Thanks,
>> >>> >
>> >>> > Lon
>> >>> >
>> >>> > On Wed, Jul 19, 2017 at 1:24 PM, Lon Varscsak <
>> [hidden email]>
>> >>> > wrote:
>> >>> >>
>> >>> >> I can also get it to throw this error:
>> >>> >>
>> >>> >> Caused by: org.apache.cayenne.FaultFailureException:
>> >>> [v.4.1.M1-SNAPSHOT
>> >>> >> Jul 19 2017 19:49:41] Error resolving fault, no matching row exists
>> in
>> >>> the
>> >>> >> database for ObjectId: <ObjectId:OrderDetailSale,
>> order_line_number=2,
>> >>> >> order_number=55663878>
>> >>> >>
>> >>> >> at org.apache.cayenne.BaseContext.prepareForAccess(BaseContext.
>> >>> java:365)
>> >>> >>
>> >>> >> at
>> >>> >> org.apache.cayenne.CayenneDataObject.readProperty(CayenneDat
>> >>> aObject.java:174)
>> >>> >>
>> >>> >> at
>> >>> >> com.smarthealth.businesslogic.production.auto._OrderDetailSa
>> >>> le.getPersonalizationDiscPercent(_OrderDetailSale.java:316)
>> >>> >>
>> >>> >> at
>> >>> >> com.smarthealth.businesslogic.production.auto._OrderDetailSa
>> >>> le.personalizationDiscPercent(_OrderDetailSale.java:319)
>> >>> >>
>> >>> >> at
>> >>> >> com.smarthealth.businesslogic.production.BillingOrderDetailS
>> >>> ales.personalizationDiscountAmount(BillingOrderDetailSales.java:26)
>> >>> >>
>> >>> >> at
>> >>> >> com.smarthealth.businesslogic.production.BillingOrderDetailS
>> >>> ales.extendedPrice(BillingOrderDetailSales.java:30)
>> >>> >>
>> >>> >>
>> >>> >> Where the OrderDetailSale object in question is new on an
>> OrderHeader
>> >>> >> which isn’t new.
>> >>> >>
>> >>> >> -Lon
>> >>> >>
>> >>> >> On Wed, Jul 19, 2017 at 1:23 PM, Lon Varscsak <
>> [hidden email]>
>> >>> >> wrote:
>> >>> >>>
>> >>> >>> Okay, I’ll see if I can work up a test case.  Note:  This only
>> >>> happens if
>> >>> >>> the objects in question are new objects (not in the db).  When it
>> >>> tries to
>> >>> >>> find the “id” in DataRowUtils it comes back with nothing, so then
>> it
>> >>> nulls
>> >>> >>> the reverse relationship out (even though at that point the reverse
>> >>> >>> relationship is in the child and has all of it’s values).
>> >>> >>>
>> >>> >>> -Lon
>> >>> >>>
>> >>> >>> On Wed, Jul 19, 2017 at 12:34 AM, Nikita Timofeev
>> >>> >>> <[hidden email]> wrote:
>> >>> >>>>
>> >>> >>>> Hi Lon,
>> >>> >>>>
>> >>> >>>> I've tried to dig dipper into your case, and I can't repeat
>> described
>> >>> >>>> behavior, all I see is that toOne
>> >>> >>>> relationship in object that moved to other context is faulted and
>> >>> >>>> resolved on next access,
>> >>> >>>> and no reverse relationships are affected. And that I assume is
>> >>> >>>> expected behavior.
>> >>> >>>>
>> >>> >>>> And even more I can't figure out case when line 194 in
>> DataRowUtils
>> >>> can
>> >>> >>>> be hit.
>> >>> >>>> May be you can provide some simple test case?
>> >>> >>>>
>> >>> >>>> On Mon, Jul 17, 2017 at 9:14 PM, Lon Varscsak <
>> >>> [hidden email]>
>> >>> >>>> wrote:
>> >>> >>>> > Okay, that didn’t work.
>> >>> >>>> >
>> >>> >>>> > https://www.dropbox.com/s/68hsculni16ucg3/Screen%20Shot%2020
>> >>> 17-07-13%20at%2010.50.24%20AM.png?dl=0
>> >>> >>>> >
>> >>> >>>> > -Lon
>> >>> >>>> >
>> >>> >>>> > On Mon, Jul 17, 2017 at 11:06 AM, Lon Varscsak
>> >>> >>>> > <[hidden email]>
>> >>> >>>> > wrote:
>> >>> >>>> >
>> >>> >>>> >> Try this:
>> >>> >>>> >>
>> >>> >>>> >> http://gofile.me/34oeM/YdPU7U4j1
>> >>> >>>> >>
>> >>> >>>> >> On Mon, Jul 17, 2017 at 10:08 AM, Andrus Adamchik
>> >>> >>>> >> <[hidden email]>
>> >>> >>>> >> wrote:
>> >>> >>>> >>
>> >>> >>>> >>> Unfortunately the mailing list strips attachments. Could you
>> post
>> >>> >>>> >>> the
>> >>> >>>> >>> image elsewhere, like GoogleDrive or Dropbox?
>> >>> >>>> >>>
>> >>> >>>> >>> Andrus
>> >>> >>>> >>>
>> >>> >>>> >>> > On Jul 13, 2017, at 8:51 PM, Lon Varscsak <
>> >>> [hidden email]>
>> >>> >>>> >>> wrote:
>> >>> >>>> >>> >
>> >>> >>>> >>> > I found the line that’s nulling it out…I just don’t
>> understand
>> >>> at
>> >>> >>>> >>> > this
>> >>> >>>> >>> deep level what’s going on.  Here’s the strack trace:
>> >>> >>>> >>> >
>> >>> >>>> >>> > On Thu, Jul 13, 2017 at 10:43 AM, Lon Varscsak
>> >>> >>>> >>> > <[hidden email]>
>> >>> >>>> >>> wrote:
>> >>> >>>> >>> > I have an object (that’s new) in ObjectContextA that has a
>> >>> >>>> >>> > relationship
>> >>> >>>> >>> to another new object (same OC) which also has a reverse
>> >>> >>>> >>> relationship.  I
>> >>> >>>> >>> then create a child of that OC (ObjectContactB) and grab a
>> local
>> >>> >>>> >>> version of
>> >>> >>>> >>> the first object.  At that time, the relationship object (and
>> >>> it’s
>> >>> >>>> >>> reverse)
>> >>> >>>> >>> is there and all is good in the world.
>> >>> >>>> >>> >
>> >>> >>>> >>> > The moment I touch the object (setting a simple property
>> with
>> >>> >>>> >>> writeProperty) in the relationship the reverse relationship
>> gets
>> >>> >>>> >>> nulled
>> >>> >>>> >>> out.  Any thoughts as to why this might happen?
>> >>> >>>> >>> >
>> >>> >>>> >>> > -Lon
>> >>> >>>> >>> >
>> >>> >>>> >>>
>> >>> >>>> >>>
>> >>> >>>> >>
>> >>> >>>>
>> >>> >>>>
>> >>> >>>>
>> >>> >>>> --
>> >>> >>>> Best regards,
>> >>> >>>> Nikita Timofeev
>> >>> >>>
>> >>> >>>
>> >>> >>
>> >>> >
>> >>>
>> >>>
>> >>>
>> >>> --
>> >>> Best regards,
>> >>> Nikita Timofeev
>> >>>
>> >>
>> >>
>>
>>
>>
>> --
>> Best regards,
>> Nikita Timofeev
>>



--
Best regards,
Nikita Timofeev
Loading...