Re: EOEditingContext conceptual question
Re: EOEditingContext conceptual question
- Subject: Re: EOEditingContext conceptual question
- From: Miguel Arroz <email@hidden>
- Date: Sun, 11 Sep 2005 23:56:32 +0100
Hi!
On 2005/09/11, at 23:14, Mike Schrag wrote:
I'm assuming that the list is generated by an EOFetchSpecification
against the SMTicket entity. EOFetchSpecs don't return uncommitted
instances of entities (even when using the EOEditingContext that
you inserted into). That's most likely the cause of the behavior
you're seeing. Once you saveChanges, the in-memory SMTicket
becomes a committed in-database SMTicket and will then be returned
by your EOFetchSpec. This can be deceptive if you don't expect it ...
You are right! I didn't mention, but I'm using a fetch
specification, so that I may get all the "open" tickets (the closed
ones will not show up). That explains the behaviour of my app.
Incidentally, the pattern you're using of createAndInsert'ing in
the constructor of your AddTicket with the defaultEditingContext is
probably going to cause you problems with the use-case where
someone hits the AddTicket form and then navigates away. You then
have an empty SMTicket in your session editingcontext. The next
saveChanges executed on that editingcontext (regardless of what you
are doing it for) will then attempt to commit the empty SMTicket EO.
Yap... didn't think about that! :-( I'm still not used to the web
paradigm, where an user may literally do what he wants... on desktop
apps, the environment is a lot more controlled, we know that, from
some state, users may not directly jump to another state, etc. Thanks
for your help and suggestions!
Yours
Miguel Arroz
A better approach is to either a) create a child or peer editing
context and insert into that -- which when someone navigates away
will cause the EC to get garbage collected, cleaning up your half-
created SMTicket -- in add() you would saveChanges() on your new EC
(and if it's a child then saveChanges() on the parent EC) -- note
this way requires you to consider locking -- see Chuck's book, the
archives of this list, or Project Wonder for options; b) bind your
variables to an NSMutableDictionary instead the EO itself and then
createAndInsert an EO with the contents of that dictionary in the
add() method; or c) variation on the dictionary -- have a component
with copies of the fields of the SMTicket and bind to those, and
then fill in the EO in add().
ms
"I felt like putting a bullet between
the eyes of every Panda that wouldn't
scr*w to save its species." -- Fight Club
Miguel Arroz
http://www.ipragma.com
_______________________________________________
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