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 Tue, 25 Jul 2017 15:41:33 GMT
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 <ntimofeev@objectstyle.com>
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 <lon.varscsak@gmail.com>
> 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 <lon.varscsak@gmail.com>
> > 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 <
> >> ntimofeev@objectstyle.com> 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 <lon.varscsak@gmail.com>
> >>> 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 <
> 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(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 <
> 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
> >>> >>>
> >>> >>>
> >>> >>
> >>> >
> >>>
> >>>
> >>>
> >>> --
> >>> Best regards,
> >>> Nikita Timofeev
> >>>
> >>
> >>
>
>
>
> --
> Best regards,
> Nikita Timofeev
>

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