Re: [Modeling-users] saveChanges() doesn't change globalID

[Sebastien B. <sbi...@us...>]

Marcos Dione <md...@vi...> wrote:
>     the usage of this rollbackable thing is to develop a=20=20=20=20=20=
=20=20=20
>     insert-modify-delete part of a bigger application. the user can be=20=
=20=20=20
>     handling only one instance at a time, but this instance could have
>     several other instances of other (or the same) related to it, and
>     being edited at the same time.
>=20
>     e.g, here we have a Persona() entity, related with several
>     PostalAddr(). the user can be editing only one Persona, but several
>     (all the related ones) PostalAddr. the rollback mechanisms throws
>     away the ec, and repopulates starting from the Persona, so the
>     rollback applies to the persona and its related objects. maybe later
>     we'll add support for rollbacking individual PostalAddr's.

Given this, and what you say about new objects (simply calling the
constructor), I wonder why you need to explicitly track the rollback
thing.

  I mean, if you simply drop the existing ECs and get a brand new one,
  then ask it for the Persona() (either from a given fetch qualifier or
  from its globalID), and then its postal addr. with
  person.getPostalAddresses(), then you instantly get what is in the db
  --no need to keep raw rows under the pillow, just because an EC is in
  fact a transaction at the object level: until you saveChanges(), the
  changes are not persistent and there's nothing to do to retrieve the
  objects as they are stored in the db.

I suspect I'm missing something important here --because if you simply
want to rollback, then you wouldn't try to (re) add newly inserted
objects (PostallAddresses I guess) from the beginning.  This probably
means that you want to rollback some changes, while keeping newly
inserted objects, and maybe(?) how relationships between newly inserted
and 'from-db' objects were modified.  Sorry if I did not understand you
right, again a sample code might help, showing what happens before a
rollback, and what you want to get after the custom rollback happens.

> >   If what you see is newly inserted objects not getting their
> >   corresponding KeyGlobalID after ec.saveChanges(), but keeping their
> >   old TemporaryGlobalID instead, this is definitely a bug, and a serious
> >   one, and I'm very interesting in seeing the code triggering it.
>=20
>     good, this seems to be the thing happening.

  Now, whatever your use-cases are and what is behind, I want to make it
  clear that, if this is the bug you're observing, this is a serious one
  that should be addressed as quickly as possible.  If you do not have
  the time to extract the behaviour but have some code revealing it that
  you do not want to disclose on a public list, please email me
  privately and we'll work together on making from your experience a
  public test revealing the bug.

    Thanks for your time!

-- S=E9bastien.
=20=20





Marcos Dione <md...@vi...> wrote:
> On Thu, Sep 09, 2004 at 12:41:11PM +0200, Sebastien Bigaret wrote:
> > >     given a EditingContext, there a re two kind of objects registered=
 at
> > > the moment fo saveChanges(): from-database ones (globalID() is an
> > > instance of KeyGlobalID), and new ones (globalID() is an instance of
> > > TemporaryGlobalID). when I roll back, I do the following:
> > >=20
> > > * 'hold' the model: any from-database object gets hold by means of
> > > snapshot_raw(). new ones are simply forgoten.
> > >=20
> > > * build a new EditingContext.
> > >=20
> > > * repopulate it with the old objects. from-database ones get reinsert=
ed
> > > via faultForRaw(), and new ones simply requesting a new instance of t=
he
> > > proper class.
> >=20
> > Could you be a little more explicit about the use cases behind this
> > rollback mechanism?=20
>=20
>     I'll try :) the general idea is to be able to get the previous state
> of any object inserted in the ec. this previous state for from-db
> instances is the state in the db, that's why I foult them and then let
> Modeling refetch the values on any reference to any of its attributes.
> for new ones, it would be an empty model, like the one get w/ just
> calling the proper constructor. e.g., say I have a Persona entity, an
> empty model is the result of calling Persona().
>=20
> > Are "from-db objects" changed within the EC?
>=20
>     could be. a rollback must revert their properties' values to the ones
> in the db.
>=20
> > Or do
> > you simply want to remove the inserted ones,=20
>=20
>     as the way I sue it, you can't add several empty instances, so a
> rollback after modifing it just gives me an empty model again. also, no
> more that one model can be handled at the same time.
>=20
>     the usage of this rollbackable thing is to develop a=20=20=20=20=20=
=20=20=20
>     insert-modify-delete part of a bigger application. the user can be=20=
=20=20=20
>     handling only one instance at a time, but this instance could have
>     several other instances of other (or the same) related to it, and
>     being edited at the same time.
>=20
>     e.g, here we have a Persona() entity, related with several
>     PostalAddr(). the user can be editing only one Persona, but several
>     (all the related ones) PostalAddr. the rollback mechanisms throws
>     away the ec, and repopulates starting from the Persona, so the
>     rollback applies to the persona and its related objects. maybe later
>     we'll add support for rollbacking individual PostalAddr's.
>=20
> > and to revert the
> > persistent ones to the state they have in the db?
>=20
>     yeap.
>=20
> > Plus, when you say you repopulate the new EC with the new ones, how is
> > this done?
>=20
>     o=3D Persona ()
>     ec.insert (o)
>=20
>     (more or less)
>=20
> >   If what you see is newly inserted objects not getting their
> >   corresponding KeyGlobalID after ec.saveChanges(), but keeping their
> >   old TemporaryGlobalID instead, this is definitely a bug, and a serious
> >   one, and I'm very interesting in seeing the code triggering it.
>=20
>     good, this seems to be the thing happening.
>=20
> >   More details in case you're interested and you want to investigate
> >   this: changing newly inserted objects gIDs is done at the very end of
> >   the saveChanges() process, and DBContext.finalizeCommitChanges() is
> >   responsible for this. It broadcasts a GlobalIDChangedNotification,
> >   handled by ec.handleNotification() (among other possible observers)
> >   which in turn re-registers the object with its newly assigned
> >   KeyGlobalID.
>=20
>     good! I'll try to see it now and post any clues later.