cayenne-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lon Varscsak <lon.varsc...@gmail.com>
Subject Re: Need a push in the right direction (parent-child object context and disappearing relationship)
Date Thu, 20 Jul 2017 01:08:29 GMT
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 <lon.varscsak@gmail.com>
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 <lon.varscsak@gmail.com>
> 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 <
>> ntimofeev@objectstyle.com> 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 <lon.varscsak@gmail.com>
>>> 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 <lon.varscsak@gmail.com
>>> >
>>> > wrote:
>>> >
>>> >> Try this:
>>> >>
>>> >> http://gofile.me/34oeM/YdPU7U4j1
>>> >>
>>> >> On Mon, Jul 17, 2017 at 10:08 AM, Andrus Adamchik <
>>> andrus@objectstyle.org>
>>> >> 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 <lon.varscsak@gmail.com>
>>> >>> 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 <
>>> lon.varscsak@gmail.com>
>>> >>> 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
>>>
>>
>>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message