Post by Marcos Dionethe 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.
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.
Post by Marcos DionePost by Sebastien BigaretIf 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.
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ébastien.
Post by Marcos DionePost by Sebastien BigaretPost by Marcos Dionegiven 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
* '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().
Post by Sebastien BigaretAre "from-db objects" changed within the EC?
could be. a rollback must revert their properties' values to the ones
in the db.
Post by Sebastien BigaretOr 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.
Post by Sebastien Bigaretand to revert the
persistent ones to the state they have in the db?
yeap.
Post by Sebastien BigaretPlus, when you say you repopulate the new EC with the new ones, how is
this done?
o= Persona ()
ec.insert (o)
(more or less)
Post by Sebastien BigaretIf 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.
Post by Sebastien BigaretMore 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.