Re: Hollow object throwing FaultFailureException

From: Lawrence Gerstley (lawger..mail.com)
Date: Wed Oct 07 2009 - 23:52:52 EDT

  • Next message: Michael Gentry: "Re: Hollow object throwing FaultFailureException"

    Nevermind--your first suggestion of invalidating the object after healing
    the missing row is working like a champ. Thanks!

    On Wed, Oct 7, 2009 at 3:53 AM, Andrey Razumovsky <
    razumovsky.andre..mail.com> 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 <lawger..mail.com>
    >
    > > 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 <
    > > razumovsky.andre..mail.com> 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 <lawger..mail.com>
    > > >
    > > > > 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 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



    This archive was generated by hypermail 2.0.0 : Wed Oct 07 2009 - 23:54:32 EDT