modeling-users

[Modeling-users] dirty deeds done dirt cheap

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

User-Agent: Mutt/1.3.28i


    I have the following problem: I have a form where I can edit
Modeling Entities. if you perss a button, it gets saved (the changes, I
mean). but if you press that other button, it should revert any changes
done so far. the Modeling Entities are not saved yet (if you saved
alredy, I'm sorry :)

    flipping the docs I see that EditingContext is capable of tell
wether it's dirty or not. but I think it would be better if I could ask
the Entity if it's dirty or not; and, being dirty, ask it to ignore any
changes not saved (which I think will resort to reload from the db)... 

    note that this seems to have nothing to do with undo/redo, or at
least I think so.

Re: [Modeling-users] dirty deeds done dirt cheap

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

User-Agent: Mutt/1.3.28i

On Wed, Mar 24, 2004 at 05:19:41PM -0300, Marcos Dione wrote:
>     flipping the docs I see that EditingContext is capable of tell
> wether it's dirty or not. but I think it would be better if I could ask
> the Entity if it's dirty or not; and, being dirty, ask it to ignore any
> changes not saved (which I think will resort to reload from the db)... 

    I note two things: first, asking an Entity if it's dirty or not is
impossible w/o an EC, so is unreasonable to ask for it. second, the
answer seems to be to use nested EC's, but if I do it that way, for
reseting I would need to discard the dirty EC, take a new one and
repopulate it with the original values (most probably this two EC's will
be child of one master EC at different times).

    what's not clear for me is how to repopulate the second EC.

Re: [Modeling-users] dirty deeds done dirt cheap

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

Marcos Dione <md...@vi...> wrote:
>=20
> On Wed, Mar 24, 2004 at 05:19:41PM -0300, Marcos Dione wrote:
> >     flipping the docs I see that EditingContext is capable of tell
> > wether it's dirty or not. but I think it would be better if I could ask
> > the Entity if it's dirty or not; and, being dirty, ask it to ignore any
> > changes not saved (which I think will resort to reload from the db)...=
=20
>=20
>     I note two things: first, asking an Entity if it's dirty or not is
> impossible w/o an EC, so is unreasonable to ask for it.

Absolutely, the standard way is to ask the ec for that --even if some of
the CustomObject's methods can be relative to the editingContext(), such
as globalID().

> second, the
> answer seems to be to use nested EC's, but if I do it that way, for
> reseting I would need to discard the dirty EC, take a new one and
> repopulate it with the original values (most probably this two EC's will
> be child of one master EC at different times).
>=20
>     what's not clear for me is how to repopulate the second EC.

Repopulating the EC simply consists in fetching the objects, or asking
for a particular object given its globalID (ec.faultForGlobalID()), etc.

Now you may need a simpler way of doing this, esp. if you're dealing
with one object or a few: the nested ECs are very handy when the
modifications of the graph of objects can be very intensive and you do
not want to track which changes occured. But if you know exactly which
object(s) is/are impacted (which is probably the case in any simple
form), you may just ask for forgetting about the changes --what you were
asking for in your 1st post.

I've just submitted patch #922822 with an up-to-date version of one I
posted a year ago (almost: 26 Mar 2003 :/ )
https://sourceforge.net/tracker/index.php?func=3Ddetail&aid=3D922822&group_=
id=3D58935&atid=3D489337

The comments there contain references of the messages talking about
this feature.

  It also contains a test case for that. The idea is that you simply
call ec.refaultObject(obj), and the object is reverted back to a fault,
ready to be retrieved from the database next time one of its
properties' value is needed.

  It's not been extensively tested, and should be used w/ care for the
  moment being; see comments for patch #922822. As noted there, it's
  been asked regularly, but even then I've never heard that it has been
  really tested. Handle w/ care ;) but hopefully it will be of some
  help, and maybe we could finally make it and finally integrate this
  into the main trunk some day. So I'll be happy to hear from you if you
  find some time to experiment!

-- S=E9bastien.

Re: [Modeling-users] dirty deeds done dirt cheap

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

User-Agent: Mutt/1.3.28i

On Thu, Mar 25, 2004 at 01:03:00AM +0100, Sebastien Bigaret wrote:
> Repopulating the EC simply consists in fetching the objects, or asking
> for a particular object given its globalID (ec.faultForGlobalID()), etc.

    well, I was thinking in that yesterday when I left work... is it too
ugly to do it that way? will it mess with something?

> Now you may need a simpler way of doing this, esp. if you're dealing
> with one object or a few: the nested ECs are very handy when the
> modifications of the graph of objects can be very intensive and you do
> not want to track which changes occured. But if you know exactly which
> object(s) is/are impacted (which is probably the case in any simple
> form), you may just ask for forgetting about the changes --what you were
> asking for in your 1st post.

[snip]

>   It also contains a test case for that. The idea is that you simply
> call ec.refaultObject(obj), and the object is reverted back to a fault,
> ready to be retrieved from the database next time one of its
> properties' value is needed.
>
>   It's not been extensively tested, and should be used w/ care for the
>   moment being; see comments for patch #922822. As noted there, it's

    here are those comments:

--- paste ---
I've quickly checked the implementation & at the test I proposed there,
so here is my suggestion: you can use it as-is, given that:
    
- you're not applying it on deleted, inserted or modified objects, (BTW:
  it will become an error to refault a deleted or an inserted object)
  [UPDATE: see note, below]

- you stick to EC.refaultObject and do not try to call
  DBContext.refaultObject
	   
- you do not use it with a nested ec.
	    
(I'm not saying this won't work, it probably will... but it needs to be
tested before I can say this is supported).
--- paste ---

    that last remark applies to the last contition? from the patch, it
seems like the refaultObject is finally done by the 'master' of all the
EC's. do you think the problem would be that the 'reset' is not
'propagated' to children EC's?
    
    the other comment is (I think this is the update you mention above):
    
--- paste ---
Note: it can be safely applied on modified objects given that no
relationships have been modified (such a situation has not been tested
at all).
--- paste ---

    I'll try to make some tests in both cases.
    
    it is interesting to note that most of this patch is already in the
slice_n_sort patch. is that an error? shouldn't this other one depend on
the first one, so applying both doesn't choke?

Re: [Modeling-users] dirty deeds done dirt cheap

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

Marcos Dione <md...@vi...> wrote:
> On Thu, Mar 25, 2004 at 01:03:00AM +0100, Sebastien Bigaret wrote:
> > Repopulating the EC simply consists in fetching the objects, or asking
> > for a particular object given its globalID (ec.faultForGlobalID()), etc.
>=20
>     well, I was thinking in that yesterday when I left work... is it too
> ugly to do it that way? will it mess with something?

No it's not: GlobalIDs are especially designed to designate a specific
object/row, and using a child EC has several advantages. I was just
saying then that the features it provides [mostly: "OO-transactions" and
inheriting the changes made in the parent EC(s)] may be oversized if all
you need is to forget the state of one or a few objects.

And if you mess with something when doing it this way, that means you've
probably been bitten by a bug.

>
[...]
> --- paste ---
> I've quickly checked the implementation & at the test I proposed there,
> so here is my suggestion: you can use it as-is, given that:
>=20=20=20=20=20
> - you're not applying it on deleted, inserted or modified objects, (BTW:
>   it will become an error to refault a deleted or an inserted object)
>   [UPDATE: see note, below]
>=20
> - you stick to EC.refaultObject and do not try to call
>   DBContext.refaultObject
>=20=09=20=20=20
> - you do not use it with a nested ec.
>=20=09=20=20=20=20
> (I'm not saying this won't work, it probably will... but it needs to be
> tested before I can say this is supported).
> --- paste ---
>=20
>     that last remark applies to the last contition? from the patch, it
> seems like the refaultObject is finally done by the 'master' of all the
> EC's. do you think the problem would be that the 'reset' is not
> 'propagated' to children EC's?

- Exactly, it is indeed propagated down the EC hierarchy, then to the
  ObjectStoreCoordinator and ultimately to the DatabaseContext
  responsible for the object's entity.

- The last remark was targetted to the three conditions. You may
  wonder why making this available to non-modified, permanent objects ->
  reason is that it was initially designed to make it possible to
  "release" objects in ECs, e.g. to keep the number of held objects
  under a certain limit: releasing an object also release memory (from
  db caches, mostly).

    However it's applicable to modified objects, as shown in the test.

- About the propagation of reset up the EC hierarchy: it's not done and
  this is a problem. Most probably, the rest of an object wil also reset
  it in its parents. But even then, this is only a proposal for the
  default behaviour, and one ec should be able to provide its own
  response to the refault notification coming from a parent, for example
  through a delegate.


NB: however to test it w/ modified objects the following lines in
    EC.refaultObject() should be disabled --my fault:

        if gid in self._pendingUpdatedObjects+self._updatedObjects:
          raise ValueError, 'Cannot refault a modified object'

>=20=20=20=20=20
>     the other comment is (I think this is the update you mention above):
>=20=20=20=20=20
> --- paste ---
> Note: it can be safely applied on modified objects given that no
> relationships have been modified (such a situation has not been tested
> at all).
> --- paste ---
>=20
>     I'll try to make some tests in both cases.
>=20=20=20=20=20
>     it is interesting to note that most of this patch is already in the
> slice_n_sort patch. is that an error? shouldn't this other one depend on
> the first one, so applying both doesn't choke?

You're right!  I was not even able to find a difference, it's completely
included in patch #892454... I have several tests configurations here
and it seems that one got integrated in the other. Thanks for noticing,
I'll add a note to the patches'page.

-- S=E9bastien.