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.