Re: Multithreading EOAccess

> Even changing not-class properties will likely break snapshoting in
> some horrible way.

The reason I originally asked the question is that I use a piece of 
code that counts the row matched by a fetch specification by 
temporarily adding a special attribute to the entity. That code stems 
from Eric Noyau's BugTracker sample. I'd trust him to know what he is 
doing. However it seems obvious that such changes to the entity won't 
fare well with multi-threading.

> Can't you perform your dynamic model configuration at start up time
> before creating all the concurrent EOF stacks ?

 From the top off my head, I can think of 4 types of modifications I 
could imagine making to a model at runtime:

- Changing connection dictionary information. I do that at application 
launch time. Thus no harm is done. I can however imagine that someone 
might want to have one EOF stack per WOSession and connect each with a 
different user name. As long as it is not done concurrently and as 
handling dropped connections is provided for I can't see much harm.

- Performance tuning. Let's say I have an enumeration entity that 
hardly ever changes. For most users it should be read-only and cached. 
Yet an admin user might have to modify it occasionally.   It would be 
tempting to create a distinct object store coordinator for that user's 
session and give it a modified model. This is not so much about 
dynamically modifying the model, but about attaching a different model 
group to a given EOF stack. I really should stop using 
EOModelGroup.defaultGroup() in code that I expect to be reusable. I 
guess I should always ask the editing context.

- "Hacking". I have a colleague who mapped EOs to a badly designed DB. 
He ran into a situation where inheritance seems natural but where the 
underlying tables have entries with conflicting primary keys. He 
modelled inheritance and uses in the Java code. At application startup 
he breaks inheritance for the mapping to actually work. This happens at 
application startup. Should not be a problem.

- "Smart trickery". Like adding a count(*) attribute to count rows 
matched by a fetch spec at low cost. I guess there might also be 
situations where a relationship's join might need to be set as inner 
join for one fetch and as outer join for the other.

Thinking of it, the solution to the "count(*)" thing might be to create 
temporary clones of the entity one wants to modify. I can't see much 
harm being done by creating a temporary entity of which no EO is ever 
created.

Thinking again of it it would be great if Apple could improve fetch 
specifications to counting instead of fetching. It's often useful to 
get an idea of the number of records before (or instead) of actually 
fetching.

As for the the relationship thing. I never actually had to do it. 
Though of it once and in the end found a better way to do it.

Oh well, I guess being aware of the risks already helps. In the end a 
model group for each EOF stack might be the best way to go. One just 
has to hope that none of Apple's code relies on always using the 
default model group.

Pierre.

--
Got time to spare? Why don't you visit my web site?
http://homepage.mac.com/I_love_my