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...
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...
