On May 16, 2006, at 1:05 PM, Dev WO wrote:
-when creating an editing Context inside my direct action (like suggested by Robert), the Editing context gets created each time the action is called and so fetches the database every-time, right?
No. It depends on how you access your data. If you do a fetch using a fetch specification, EOF will always go to the database, but if the objects in your database context are not stale and setRefreshesRefetchedObjects is false, it will use the values in the database context. If you have to-one relationships, they will most likely be populated from the database context if you've fetched it before and again, it isn't stale.
-if I'm creating an Editing Context inside a Component, I've got some sort of caching for this component shared among different users?
I mean if I have 2 visitors who are adding a commentary to a news for exemple, at the same time, when saveChanges is called, the last commentary posted will raise an exception complaining about the cache not the same as what's in the datastore (the first commentary was saved in between)? or maybe there's a way to tell the EC to just "add" the new entry?
You need to consider how your model deals with these types of things. If you're getting an optimistic locking error, it's because you've marked an attribute with a lock icon in EOModeler and that attribute was changed by another user. There are many techniques to avoid this type of problem, but the problem can often be mitigated with a good model. Of course, as Chuck would tell you, you must ALWAYS be prepared to catch the exception and deal with it, even if you mitigate it with other methods. I would consider having a different object for each users changes. If you need to have them edit the exact same stuff, you might consider some type of internal locking mechanism.
-Is there anything like notification I could issue from the back office through the framework to invalidate a specific Editing context or a specific object?
There are already notifications that occur inside EOF when things change. For instance, if you modify an object and save it in one editing context, another peer context will recognize the change because of internal EOF notifications. However, you must consider the fact that you will eventually have multiple instances of your application running (possibly on different servers), so any single application solution is doomed eventually. There are a few tools available that communicate between instances that either carry the entire changed object across or send the global ID for invalidation. This is certainly something to look at, but I suggest you get more familiar with editing contexts and database contexts before considering this.