Re: [RFC/PATCH] EOEntity

[David Ayers]

Richard Frith-Macdonald wrote:

> On Thursday, November 28, 2002, at 02:57  pm, Manuel Guesdon wrote:
>
> > On Thu, 28 Nov 2002 12:20:50 +0100 David Ayers <d.ayers@inode.at> wrote:
> >
> > > | I'm wondering if anyone is considering this patch?  (Which is 
> > > admittedly
> > > | a hack :-) but I wanted to get my tests working.)
> >
> > I'll try to check it tommorow or this week-end.
>
> I just did it ...  It looked correct/harmless, so I added it ... but 
> if it's not too much bother it would be nice for you to check it too.  
> You are all much more familiar with this than I am, so my checking is 
> really only good for localised issues rather than overall 
> architectural ones.

I was just about to say....
"Don't worry about then.  I'll try to submit something more complete 
(maybe the beginning of next week sometime)."

> > > | Or rather if someone
> > > | is working on restructuring the caching/laziness-mechanisms in 
> > > EOEntity?
> > > |   If not, I'll try to revamp it a bit as there are similar 
> > > problems with
> > > | other ivars that should be adressed.
> >
> > Which kind of problem ? 
primaryKeyAttributes
An assertion triggers the creation of the _attributes from potential 
property list. (This isn't a real problem, but it kind of defeats the 
purpose of lazy attribute initilazation, but then again, I'm not sure 
whether the lazy initialization makes sense for attributes anyhow.)

addAttribute:
My patch didn't take into account a freshly loaded model (initialized by 
plist) in which the entities _attributesByName hasn't been initialzed 
yet and recieves an addAttribute method.  This will initialize 
_attributesByName to contain only the added object and and the objects 
from _attributes never find thier way into this dictionary :-( (So maybe 
it would make sense to revert this patch, eventhough I don't know how 
likely the scenario is.)

fetchSpecificationNames:
The ivar _fetchSpecificationNames returned by this method is only set 
during add/removeFetchSpecification(:)(N/n)amed: so 
if _fetchSpecificationDictionary was initilized by 
initWithPropertyList:owner: this will return nil.

And I would look over the rest of cached objects and lazy initializations.

I'm also thinking of submitting a patch to EOModel to raise on 
entityForClass: if the classes arn't unique for the entity.  But I would 
like to here your comments first.

> Speaking of other problems ... it's not really a big problem 
> necessarily, but I think it would be nice to re-implement the 
> Fault/FaultHandler code somewhat...
>
> At the moment objects get morphed into faults by -
> 1. changing the isa pointer
> 2. overwriting the next four bytes of ivar data with a pointer to the 
> fault handler.
> The second part is a theoretical problem if a class being made into a 
> fault doesn't actually have any ivars beyond the isa pointer ... this 
> may not be possible in practice, but I don't like it.
>
> Because of this messing with the initial ivars, where an object being 
> faulted is a garbage collecting object, the linked list of pointers in 
> the garbage collection is screwed up  - which means that the faulting 
> mechanism also has to be intimately aware of the GC mechanism (and 
> hack it to continue working), and also that the GC mechanism has to 
> work entirely through methods rather than accessing the linked list 
> pointer ivars directly.  This adds complexity to the faulting 
> mechanism and makes GC passes quite inefficient.
>
> If we used a global map table to map fault objects to their handlers, 
> we could make an object into a fault simply by changing its isa 
> pointer and adding it to the mapping.
> This would mean that the faulting code could be simplified a bit, and 
> also that the GC could run faster because we would not have interfered 
> with the linked list pointers.
>
> Or am I missing something that means doing that would be a bad idea?

Do you mean that the values of the ivars (the GC-linke list) will 
effectively exist while the object is a fault and therefor the linked 
list can still be accessed and manipulated? But wouldn't firing the 
fault later restore the "old/orignal" linked list values?  That would 
still mean the fault handler would need to know which ivars to restore 
so that it will leave the GC ivars alone.  But we wouldn't have to 
message (i.e. fire) during GC-passes, which is a definate plus.  But 
maybe you can insure that the fault is fired before any manipulation 
takes place, then that shouldn't be a problem.

Ultimatly I would like to work out a mechanism that doesn't need GC. 
But since were still quite a bit away from that, it sounds like a good 
approach.

Cheers,
Dave