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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> > > 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 < > >> [email protected]> 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 <[email protected]> > >>> 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 < > [email protected]> > >>> > 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 < > [email protected]> > >>> >> 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 > >>> >>> <[email protected]> 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 < > >>> [email protected]> > >>> >>>> 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 > >>> >>>> > <[email protected]> > >>> >>>> > wrote: > >>> >>>> > > >>> >>>> >> Try this: > >>> >>>> >> > >>> >>>> >> http://gofile.me/34oeM/YdPU7U4j1 > >>> >>>> >> > >>> >>>> >> On Mon, Jul 17, 2017 at 10:08 AM, Andrus Adamchik > >>> >>>> >> <[email protected]> > >>> >>>> >> 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 < > >>> [email protected]> > >>> >>>> >>> 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 > >>> >>>> >>> > <[email protected]> > >>> >>>> >>> 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 >
