Re: deep down NPE in EOF
Re: deep down NPE in EOF
- Subject: Re: deep down NPE in EOF
- From: Ray Kiddy <email@hidden>
- Date: Sun, 11 Nov 2007 14:51:11 -0800
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.
My description seems vague, but it is hard to know without actually
seeing the model. It is amazingly hard to describe a model accurately
enough to diagnose a problem. When someone describes a model they
usually leave out the part they left out, if you get me.
Let me know if you try something based on what I have said here, and
if it works.
thanx - ray
On Nov 4, 2007, at 7:32 PM, Chuck Hill wrote:
On Nov 4, 2007, at 8:09 AM, Zak Burke wrote:
I'm getting a strange NPE from deep down in EOF that I can't
figure out. I think it might be related to some slightly funky
modeling I'm doing,
It is. :-)
but my EOs work fine in other places so I'm not sure why they're
broken here.
Here's the funkiness: I have two models -- NameStore and MyApp.
NameStore contains a single EO, StoredName. MyApp has an EO
MyAppPerson that extends StoredName, but the restricting
qualifier is just "id > 0", that is, all StoredName EOs are
MyAppPerson EOs. Basically, we have lots of (non-WO) apps that
use the StoredName table and have their own tables joined to it.
I modeled it in WO this way to keep the NameStore EO pristine --
all it does is hand out names -- while allowing other apps to
tack things onto a local EO that extends StoredName.
What I want to do is retrieve a StoredName and then bless it
into existence by re-fetching it as a MyAppPerson
Can't. When you fetch it as a StoredName, EOF associates the
GlobalID with that entity. When you re-fetch it as MyAppPerson,
EOF will still treat it as a StoredName.
You are going to have to fetch it as a MyAppPerson the first time.
Chuck
so I can access all its related objects. Because the StoredName
and the MyAppPerson share the same primary key value, I'm just
passing storedName.id() to a MyAppPerson method that retrieves
items by their PKs.
try {
return (MyAppPerson) EOUtilities.objectMatchingKeyAndValue(ec,
MyAppPerson.ENTITY_NAME, MyAppPerson.ID_KEY, id);
} catch (EOObjectNotAvailableException e) {
throw new RuntimeException("An MyAppPerson identified by " + id
+ " could not be found.");
} catch (EOUtilities.MoreThanOneException e) {
throw new RuntimeException("More than one MyAppPerson identified
by " + id + " was found.");
}
The fetch works fine; I get an object back. But EOF explodes
when I true access it, even just item.toString() to print it to
a log (stacktrace below). It appears to be exploding after
traversing an optional to-many join. I can use MyAppPerson items
elsewhere so I don't think I have modeling errors, but, well,
I'm totally stumped. Any ideas?
TIA,
zak.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40ganymede.org
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:
This email sent to email@hidden