Hi Ted,
You have stumbled upon what I believe to be one of the biggest
weaknesses in EOF, and the solutions are (again, in my opinion)
terrible. As you've noticed, if you insert things into an editing
context as they are created, you end up with a bunch of uninitialized
objects in the database. This is undesirable, so the obvious
solution is to just stop inserting them. You can get away with this
if you are willing to put up with all kinds of hassles later (EOF's
database context eventually gets all kinds of out of whack if you do,
and you get strange, hard to track exceptions in places you wouldn't
expect, but not consistently, and with no useful information about
where the problem lies. Also, things happen like sometimes a changed
object won't save it's changes to the database, but there is no
warning of any kind). So you need to insert them right away. It's
just brilliantly stupid to me that you can't initialize a java
object's state in its constructor (because then you're changing an
object before inserting it). What a concept! These are all lessons
learned from various people's hard experience with EOF, and you
should completely pay attention to them. AFAIK, Apple did not even
document that you should have EOs in an editing context before making
changes to them prior to about 2005, so don't feel bad about not
intuitively knowing these things.
As I said before, nested ECs did not work as advertised for me, due
to circumstances I have not been able to pin down. If you use an
editing context other than the session's default editing context, I
believe you have to explicitly lock and unlock it before and after
any messages to the ec or changes to the state of the objects it
contains. Unless, that is, you use a third party solution like
ERXEC, which does that locking for you. I've been using it for
awhile now, and it's worked flawlessly for me. So, at the page
level, I create a peer ec:
EOEditingContext _peerEC = ERXEC.newEditingContext();
and then use it to create the new objects:
MyEO eo = (MyEO)EOUtilities.createAndInsertInstance(_peerEC, "MyEO");
There are plenty of gotchas to be aware of here, mainly that if you
are relating your newly created objects to objects that are contained
in another editing context, you have to first bring those other
options into the peer:
OtherEO oeo = (OtherEO)EOUtilities.localInstanceOfObject(_peerEC, oeo);
(or use EOUtilities.localInstancesOfObjects(EOEditingContext, NSArray
to do a whole set at once).
Hope this helps. Getting past these issues was a bitter struggle for
me, and I wasn't even aware of all of the various problems (like
having to have an EO in and editing context before doing ANYTHING to
it) for several years. Trust me, better to start off following the
rules people have figured out from experience than to have to go back
later and refactor tons of code to fit those rules.
Mark
On May 30, 2007, at 2:41 PM, Ted Archibald wrote:
Originally in my program I was using the defaultEC to create and
insert new objects, but then started to notice I had alot of null
objects in my DB. Users are creating an object, then doing nothing
with it, then it is committed to the DB when the defaultEC is saved
at some later point.
Is this what I'm suppose to be doing to create a nested EC?:
EOEditingContext ec = new EOEditingContext(defaultEC);
Am I suppose to do any sort of locking and so forth? Should I be
using ERXEC?
_______________________________________________
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/mark%
40bluecollarsoftware.com
This email sent to [EMAIL PROTECTED]
_______________________________________________
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]
