Re: [Modeling-users] dirty deeds done dirt cheap
Status: Abandoned
Brought to you by:
sbigaret
|
From: Sebastien B. <sbi...@us...> - 2004-03-25 22:33:11
|
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.
|