Re: Partially saving the object graph. How? (Jean Pierre Malrieu)
Re: Partially saving the object graph. How? (Jean Pierre Malrieu)
- Subject: Re: Partially saving the object graph. How? (Jean Pierre Malrieu)
- From: Chuck Hill <email@hidden>
- Date: Mon, 19 Mar 2007 13:25:23 -0700
On Mar 19, 2007, at 1:17 PM, Mike Schrag wrote:
After discussing this with Chuck some, and only as a thought
exercise, because neither one of knows if you will kill yourself
(or destroy the universe) doing this. The only thing I can even
think of that MAYBE will work (and I stress MAYBE, because I don't
know the exact semantics of these uncommitted relationships across
parent-child EC's):
* create an editing context (call it parentEC)
* create Company objects in parentEC
* create a child editing context of parentEC (call it childEC)
* local instance your new Company objects into the child editing
context (which should be allowed because it's parent=>child)
create your Employee objects in childEC that relate to the Company
objects
* parentEC.saveChanges();
Note: at this point, I have no idea if this works "right" ...
TECHNICALLY, this should notify childEC that the local instanced
Company objects now have real global ids instead of temporary ones,
and it should become a "real" EO. What I don't know is what
becomes of the new to-many relationships to your uncommitted
Employee objects in childEC. Maybe this works fine. If it does,
this is the only thing I can think of that does sort of what you want.
* then sometime later:
childEC.saveChanges()
parentEC.saveChanges
If you don't save the parent, the changes won't be saved to the
database.
The catch here ("the" catch ... assuming catch #1 isn't "it doesn't
work at all"), is that you'd have to know beforehand which objects
you want to save and which ones you don't so you create them in the
proper editing context.
Or ... Just don't do this :)
My vote, FWIW.
Chuck
On Mar 19, 2007, at 3:52 PM, Chuck Hill wrote:
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.
Chuck
--
Practical WebObjects - for developers who want to increase their
overall knowledge of WebObjects or who are trying to solve
specific problems.
http://www.global-village.net/products/practical_webobjects
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40mdimension.com
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40global-village.net
This email sent to email@hidden
--
Practical WebObjects - for developers who want to increase their
overall knowledge of WebObjects or who are trying to solve specific
problems.
http://www.global-village.net/products/practical_webobjects
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden