Hello Andrey, I'm using 3.0M4, and just finished checking it with 3.0M5 (same thing happens). I'm not able to use 3.0M6, because it looks as if * org.apache.cayenne.query.SQLResultSetMapping* is missing from the build (at least it's not in my jar, and missing from the documentation).
To troubleshoot, I've looked at the collection returned from * getGraphManager().registeredNodes()* before and after the * unregisterNode(node)* call, and the call seems to have no effect. If I'm not misunderstanding this, I can log it in Jira--I've opened an account there. I was just concerned that I was going about it incorrectly. Cheers--Lawrence On Wed, Oct 7, 2009 at 4:53 AM, Andrey Razumovsky < [email protected]> wrote: > What version of Cayenne are you using? I can have a look. To speed up > things, you can submit a JUnit test > > 2009/10/7 Lawrence Gerstley <[email protected]> > > > Of course it doesn't. Sorry--it's past 2AM and I'm getting sloppy. > However, > > I made the change, and unregistered the object, then tried the assignment > > immediately thereafter and still encounter the same error: > > this.entityAssnsToEntity = > > (Entityassnstoentity) childDc.localObject( > > this.entityAssnsToEntity.getObjectId(), > > this.entityAssnsToEntity); > > Entrystate oldEntryState = > > this.entityAssnsToEntity.getToEntryState(); > > > > > > > > entityAssnsToEntity.getObjectContext().getGraphManager().unregisterNode(oldEntryState); > > entityAssnsToEntity.setToEntryState(entryState); > > childDc.commitChanges(); > > > > The error: "No matching row exists in the database for ObjectId: > <ObjectId: > > ...>" > > > > On Wed, Oct 7, 2009 at 3:07 AM, Andrey Razumovsky < > > [email protected]> wrote: > > > > > localObject() function doesn't mutate its arguments. This should be > > > rewritten as > > > this.entityAssnsToEntity = > > > childDc.localObject(this.entityAssnsToEntity.getObjectId(), > > > this.entityAssnsToEntity); > > > > > > (or create a local variable). Relationships between contexts are not > > > allowed > > > > > > 2009/10/7 Lawrence Gerstley <[email protected]> > > > > > > > Hi, > > > > So I'm trying the invalidation, but cannot do the follow-on > assignment > > > due > > > > to the objects existing in different contexts. I created a nested > > context > > > > for the creation of the healed row, as I wanted to commit that and > > > nothing > > > > else change-wise from the DataContext--reason: the user might cancel > > any > > > > ongoing changes, but the healed row should be written as soon as it's > > > > detected. However, now I can't make the assignment due to the parent > > > record > > > > existing in the parent context, and still fails when I try to move > the > > > > parent record to the nested context. Thus: > > > > > > > > try { > > > > System.out.println( > > > this.entityAssnsToEntity.getToEntryState().getOwner(); > > > > } catch (FaultFailureException e) { > > > > DataContext childDc = dc.createChildDataContext(); > > > > // Create new EntryState with builder pattern > > > > entryState = (Entrystate)ItemDirector.buildItem(new > > EntryStateBuilder(), > > > > childDc); > > > > childDc.localObject(this.entityAssnsToEntity.getObjectId(), > > > > this.entityAssnsToEntity); > > > > > > > > > > > > > > this.entityAssnsToEntity.getObjectContext().getGraphManager().unregisterNode( > > > > this.entityAssnsToEntity.getToEntryState()); > > > > this.entityAssnsToEntity.setToEntryState(entryState); > > > > childDc.commitChanges(); > > > > } > > > > > > > > ...fails due to "Cannot set object as destination of relationship > > > > toEntryState because it is in a different ObjectContext" > > > > > > > > Something must be missing here--am I off-track? > > > > > > > > Thanks--Lawrence > > > > On Wed, Oct 7, 2009 at 1:51 AM, Andrey Razumovsky < > > > > [email protected]> wrote: > > > > > > > > > Or, try to unregister HOLLOW object (using > > > > > context.getGraphManager().unregisterNode()) before any changes > > > > > > > > > > 2009/10/7 Andrey Razumovsky <[email protected]> > > > > > > > > > > > Hi, > > > > > > > > > > > > I think this happens because HOLLOW object instance is not the > same > > > as > > > > > NEW > > > > > > object you're creaing. To get rid of HOLLOW object, I reccomend > > > > > invalidating > > > > > > ENTITYASSNSTOENTITY that points to missing row after healing that > > row > > > > > (using > > > > > > ObjectContext.invalidateObjects()). > > > > > > > > > > > > Hope this helps, > > > > > > > > > > > > 2009/10/7 Lawrence Gerstley <[email protected]> > > > > > > > > > > > > Hello, > > > > > >> > > > > > >> I've searched back through old postings and seen a little bit > > about > > > > this > > > > > >> back in V2, but nothing recently. Was wondering if anyone had > any > > > idea > > > > > how > > > > > >> to handle this problem: > > > > > >> > > > > > >> Take a model including two tables: ENTITYASSNTOENTITY and > > > ENTRYSTATE, > > > > > >> where the column ENTRYSTATEID is present in both. > > > > > >> ENTITYASSNTOENTITY.ENTRYSTATEID is a FK to > ENTRYSTATE.ENTRYSTATEID > > > > > (Primary > > > > > >> Key). This is modeled as a one-to-one relationship. > > > > > >> > > > > > >> Problematically, it is possible for the ENTRYSTATEID in > > > > > >> ENTITYASSNSTOENTITY to have a key populated in it that is now > > > missing > > > > in > > > > > >> ENTRYSTATE. Certainly, this breaks integrity, but that's not > under > > > my > > > > > >> control for historical and other reasons. Thus, when I have an > > > > > >> ENTITYASSNSTOENTITY, such as eate1, and I want to get to the > > related > > > > > >> ENTRYSTATE with a "toEntryState" method, I get a hollow object > > that > > > > > refers > > > > > >> to a missing ENTRYSTATE record. If I try to access any fields > > within > > > > > that > > > > > >> record, I get and catch a "FaultFailureException", indicating > that > > I > > > > > have no > > > > > >> matching row in the database. That's all fine. > > > > > >> > > > > > >> What I need to do is to gracefully handle the error by allowing > > the > > > > > >> database to "self-heal" from such a missing record. I want to > > > populate > > > > > the > > > > > >> hollow object with values and commit it to reinsert a row in the > > > > > database to > > > > > >> correct for the integrity error, or create a new ENTRYSTATE > object > > > to > > > > > take > > > > > >> the place of the hollow and absent one. I tried to create a > > > > > >> childDataContext, move the hollow and absent ENTRYSTATE record > to > > > it, > > > > > >> populate, then commitChanges, but this still throws a follow-on > > > > > exception > > > > > >> for the missing row. If I create a new ENTRYSTATE and try to > > attach > > > it > > > > > with > > > > > >> eate1.setToEntryState(newEntryState), I also get the same error > > > > related > > > > > to > > > > > >> the absent record. When the application is restarted, however, > all > > > > works > > > > > >> fine, because the missing record was committed and persisted, > and > > > now > > > > no > > > > > >> exceptions are thrown. The issue is that I want to handle this > > > > > gracefully > > > > > >> with no necessary reloading. > > > > > >> > > > > > >> Reading from previous postings, I saw some information on having > > to > > > > > treat > > > > > >> the relationship as a many-to-one, and handling it with covering > > > > > methods. Is > > > > > >> this the only fix for this issue? Should I commit the missing > > > record, > > > > > >> invalidate the state of the ENTITYASSNSTOENTITY object and > reload? > > > > > >> > > > > > >> As always. thanks for any ideas you might have. > > > > > >> > > > > > >> Cheers--Lawrence > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > Andrey > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > Andrey > > > > > > > > > > > > > > > > > > > > > -- > > > > ============================ > > > > Lawrence Gerstley, Ph.D. > > > > PSMI Consulting > > > > > > > > Cel: 415.694-0844 > > > > > > > > > > > > > > > > -- > > > Andrey > > > > > > > > > > > -- > > ============================ > > Lawrence Gerstley, Ph.D. > > PSMI Consulting > > > > Cel: 415.694-0844 > > > > > > -- > Andrey > -- ============================ Lawrence Gerstley, Ph.D. PSMI Consulting Cel: 415.694-0844
