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?