On Mar 19, 2007, at 12:34 PM, Jean Pierre Malrieu wrote:
Le 19 mars 07 à 18:25, Chuck Hill a écrit :
Hi Jean,
On Mar 19, 2007, at 10:13 AM, Jean Pierre Malrieu wrote:
It depends on what you are doing with entity B.
If you are not modifying any B objects, then you don't need to do
anything because only updated/inserted/deleted objects in the
editing
context will get committed to the database.
I am modifying them. I am inserting them, then modifying them.
Most of the time, they are saved along with instances of entity
A. But in one app of mine, they must not be saved.
Then delete them. If you delete an inserted object, it will not
be saved.
Not possible. I need them after saving...
I think you are in trouble then.
If you are modifying A and B objects, then you can't just commit A
changes because both A and B objects must be part of the same
editing
context. If this is what you need to do, then i think you might to
reconsider your model.
Rethinking the emodel is not an option here, I am affraid.
You are going to have to re-think something!
Basically, what gets committed is determined by the editing
context you
call saveChanges() on. This is what determines the DB transaction.
Sure. I was wondering if the best strategy would be to override
saveObject() in a subclass of EOEditingContext in order to skip
entity B's inserts an updates.
Would that entail violating EOF commandments?
Here is what I would do. Go outside. Find a large road. Wait
for a bus or large truck. Lie down in front of it. You will
find this is quicker and less painful. :-)
Not being very tall, and lying parallel to the road, I was hoping
EOF bus would drive over me without hurting me...
It might, but if that happens it will backup and try again. EOF's
core focus is to maintain object graph consistency. Any effort on
your part to prevent this will cause havoc.
