Re: ec.saveChages gives null exception (didn't before)
Re: ec.saveChages gives null exception (didn't before)
- Subject: Re: ec.saveChages gives null exception (didn't before)
- From: Colin Clark <email@hidden>
- Date: Tue, 8 Mar 2005 10:08:38 -0500
Drew,
As far as I can understand, you don't need to expose the primary key
for this kind of a relationship. I think the problem is that you're
thinking in terms of database design, not in terms of your object
model.
I realize that the join entity in your many-to-many relationship has
extra attributes, so you can't flatten it. Flattened relationships are
nice because they hide the mechanics of how many-to-many relationship
are structured in the database from your object model. In your case,
the choice to put additional attributes in the join table suggests that
it actually has more meaning beyond just a "join table."
Anyway, it's a fine decision, but certainly doesn't require you to
expose primary keys and go back to manually setting foreign keys in
order to make a relationship. Don't fight with EOF. Double check that
your relationships are modeled correctly and use the standard methods
provided to add objects to the necessary relationships.
Though I don't know if it's causing your problem, it's my experience
that modeling EOs with their primary keys exposed as class properties
can be a bit problematic. In most cases it's not worth it. Plus, it
tends to cause your data model to suffer because it makes it too easy
to fall back to thinking about the mechanics of your database when,
with EOF, you should be thinking about relationships between real
objects.
Colin
On 8-Mar-05, at 6:48 AM, Drew Thoeni wrote:
< Florijan posted me off-list, but this seems to be a possible
explanation - with a compounding problem>
Florijan,
I do have the primary key exposed, but believe I needed to because I'm
doing "manual" joins to an unflattened table that is a many-to-many.
Here's the snippet of code that does that. Without access to the key,
classNumber(), I don't know how to make that join happen. Any
thoughts? Am I looking at this all wrong?
BookStudent newBSJoin =
(BookStudent)EOUtilities.createAndInsertInstance(ec,"BookStudent");
newBSJoin.setClassNumber(this.classNumber());
I think this may be the problem, as it is the only non-null column.
However, this happens also on updates. Which it seems it wouldn't as
the key would already existis.
Regards,
Drew
On Mar 7, 2005, at 9:04 AM, Florijan Stamenkovic wrote:
Hi...
Did you by any chance set the primary key to be a class property?
Because if you didn't, as you shouldn't in most cases, he would not
check it, and as all others are allowed to be null, there couldn't be
a validation error... But that doesn't explain that the error is
suddenly there... Nothing really explains that one so easily.. Can
you backtrace what you were doing/changing?
Just a thought...
Florijan
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
email@hidden
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