1. Not using Session EC - well, the reason I went with a peer is that
I was thinking I might want to use the batch loader outside of a
normal user session (e.g., maybe have a timer kick it off or write a
separate batch application using a command-line tool or something else
that wouldn't necessarily involve sessions). But my design allows the
client object to pass the batch loader an EC and I could just pass in
the session's default EC too (my original design). I'm still curious,
though, why when I used the default EC I didn't have the memory
problem, but when I used a peer EC I did...
You're right, a peer editing context does make sense in this situation.
I agree that you may want to reuse this kind of batch loading outside
of the context of a normal user session, and it makes sense to write
the code in a way that is not dependent on a particular type of EC.
In moderation, peer editing contexts are your friends. I guess you can
think of an EC as a mid-weight kind of a tool. You shouldn't hesitate
to create one when it's needed--that's what they're there for--however
there is some additional overhead associated with the added snapshots,
undo manager, etc., with a lot of peer ECs. That's why you ran out of
memory when using your peer + nested configuration as-is.
2. Nested EC - I use the child editing context so I can save changes
on it into the parent and get the validation exceptions without going
all the way to the database. Originally I just had one EC and it saved
changes every time, but I found that if I saved changes only at
intervals, performance improved over the course of tens of thousands
of records. But my design also includes an output file that shows all
the failed records and the exception messages associated with each. If
the save failed, I could just forget about the child EC and I wouldn't
have to keep track of which objects to tell the EC to forget. But I
didn't realize that there was a lot of overhead in this setup, so I
think based on your comments I should just call validateForSave()
instead. Each record in the batch loader file, though, creates
potentially several different related EOs. If I got a validation error
from validateForSave(), and I'm batching the saves to the DB, I can't
just call revert() on the EC ! or I'd lose all the valid EOs that
came before. I see from the javadocs that I should call
refaultAllObjects() to remove an EO from an EditingContext, but on the
face of it, I can't tell how that wouldn't also remove all the valid
EOs that are in the EC. Have to think on that one....
Now that you've explained your motivation for the additional nested EC,
it doesn't seem like a bad idea to work this way if you can handle the
overhead of the extra memory consumption. It sounds like nullifying the
undo manager did the trick for you.
Otherwise, I guess there's two more possibilities for handling
validation that I can think of. One, if you're using the standard EOF
mechanism for validation (ie. throwing
NSValidation.ValidationExceptions in validateForSave() and
validateKey()), you can specify which object encountered the validation
error when you throw the exception. So, when you save your batch of EOs
and catch a validation exception, the exception will tell you which one
was invalid.
Alternatively, as you say, you can call validateForSave() on each EO
before you move on to the next one. In some ways, it's less efficient
because it means validateForSave() will get called an extra time, but
the impact of that depends on how much work you do during validation.
The bottom line question for me now is why I don't have to do anything
special (invalidateAllObjects, change heap size, etc.) when I use the
Session's defaultEditingContext, but I do if I use a brand-new EC.
There's something going on behind the scenes in the defaultEC case
that I'm just not aware of, but should if I plan to use a peer EC. Any
ideas?
There's really nothing special going on behind the scenes with the
default editing context. It's just that with an extra peer and nested
editing context, you're adding an extra couple of layers that take up
additional memory. Ultimately, this isn't necessarily a bad thing
unless you're in a very memory constrained environment.
