On May 16, 2006, at 1:05 PM, Dev WO wrote:
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.
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.
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. Ken |
_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [email protected]
