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

[Marcos D. <md...@vi...>]

User-Agent: Mutt/1.3.28i

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:
> > 
> > * 'hold' the model: any from-database object gets hold by means of
> > snapshot_raw(). new ones are simply forgoten.
> > 
> > * build a new EditingContext.
> > 
> > * 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? 

    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().

> Are "from-db objects" changed within the EC?

    could be. a rollback must revert their properties' values to the ones
in the db.

> Or do
> you simply want to remove the inserted ones, 

    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.

    the usage of this rollbackable thing is to develop a        
    insert-modify-delete part of a bigger application. the user can be    
    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.

    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.

> and to revert the
> persistent ones to the state they have in the db?

    yeap.

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

    o= Persona ()
    ec.insert (o)

    (more or less)

>   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.

    good, this seems to be the thing happening.

>   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.

    good! I'll try to see it now and post any clues later.