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 <
razumovsky.andre..mail.com> wrote:
> Or, try to unregister HOLLOW object (using
> context.getGraphManager().unregisterNode()) before any changes
>
> 2009/10/7 Andrey Razumovsky <razumovsky.andre..mail.com>
>
> > 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 <lawger..mail.com>
> >
> > 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 ConsultingCel: 415.694-0844
This archive was generated by hypermail 2.0.0 : Wed Oct 07 2009 - 04:59:51 EDT