Hi Lawrence, I think SQLResultSetMapping became SQLResult in M6.
mrg On Wed, Oct 7, 2009 at 8:48 PM, Lawrence Gerstley <[email protected]> wrote: > 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 >
