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 <[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 >> > >
