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

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

        Hi,

Marcos Dione <md...@vi...> wrote:
>=20
>     hi all. I'm experimenting since a few months w/ building a rollback
> scheme above modeling. the problems I found were this:
>=20
>     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 reinserted
> via faultForRaw(), and new ones simply requesting a new instance of the
> proper class.

Could you be a little more explicit about the use cases behind this
rollback mechanism? Are "from-db objects" changed within the EC? Or do
you simply want to remove the inserted ones, and to revert the
persistent ones to the state they have in the db? Or...?

Plus, when you say you repopulate the new EC with the new ones, how is
this done?

(just asking all this to learn a bit more about your context)

>=20
>     this works fine, but a probblem arises: if I create a new object,
> add it to the EditingContext(), then saveChenges(), it *sometimes* gets
> converted to a from-database one (which is what I would mostly spect;
> see definition above) and sometimes it doesn't (which would not be so
> bad if it wouldn't be just 'sometimes'). keep in mind that now I'm just
> playing with only one entity, so it doesn't seem to be an entity
> problem, if you know what I mean.
>=20
>     is this possible (the sometimes part), could it be a bug in
> Modeling, or I'm just getting lucky sometimes? which would be the
> spected behaviour? if you need some code I can post it tomorrow.


I really need some code here, I'm not positively sure to see what the
problem is. What I understand follows.

  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.

  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.


-- S=E9bastien.