Re: deep down NPE in EOF
Re: deep down NPE in EOF
- Subject: Re: deep down NPE in EOF
- From: Zak Burke <email@hidden>
- Date: Mon, 12 Nov 2007 10:00:47 -0500
Ray Kiddy wrote on 11/11/07 5:51 PM:
On Nov 8, 2007, at 3:40 PM, Zak Burke wrote:
Ken Anderson wrote on 11/5/07 9:04 AM:
Since you state that all StoredName objects have MyAppPerson data,
why not just fetch MyAppPerson initially and have a to-one
relationship back to StoredName?
This is what I wound up doing. I didn't like that approach at first
because it seemed to unnecessarily clutter up the database (if
MyAppPerson has relationships but no attributes, it is exactly the
equivalent of a StoredName). But if imagine that maybe at some point
in the future, MyAppPerson will have attributes, then it clearly
becomes an EO that needs to be modeled separately.
With this implementation, EOF is now happy.
zak.
Did you try making sure that, before you did the second fetch, the
object from the first fetch was completely gone from the editing context?
The second fetch may be having this problem because it is an object
cached in the editing context, which is being accessed via the global
id, and then it is looking up an attribute of the relationship and
something is handing it back a null....
I have done this sort of entity-identity-switching before and I usually
have to write something to go through the editing context and pull all,
and I really mean all, of the the object references out.
We talked about that approach. To restate what you have said (I hope):
If StoredName and MyAppPerson have exactly the same database table
definition in the EOModel, then transforming a StoredName into a
MyAppPerson like this:
MyAppPerson.fetchByPk(storedNameInstance.pkValue())
will fail because EOF will realize that these two items represent the
same row in the DB and will reuse the existing EOGlobalId. So even
though that fetch appears to return a MyAppPerson, its really a
StoredName at heart, thus the NPE when invoking a relationship defined
on MyAppPerson but not on StoredName. We could attempt to scrub the EC
of all references to storedNameInstance, and maybe then our fetch would
work. (Oh, but what if wasn't just the EditingContext that had
reference? What about the DatabaseContext? What if ...?)
We concluded that this approach should probably technically worked, but
that it constituted sneaking around behind EOF's back, and that usually
leads to trouble. So: we decided the cleanest approach would be to base
StoredName and MyAppPerson on separate tables.
zak.
_______________________________________________
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