In your jbosscmp-jdbc.xml file you have in part
So this end of the relationship is not defining any
key fields. You need to define this the same way as you
did in the other direction, e.g., using the @jboss:relation tag.
don't i only need this end of the relationship defined if it is bi-directional?
Oh, right, you're doing one-to-many. Don't
know why you're getting an error message
about relation-table mapping.
Looking more closely I see a couple of
possible problems with your jbosscmp-jdbc
file. Or perhaps I've got something turned
around -- it's easy to do with this stuff.
To define the relationship ultimately the
detail table will need columns corresponding
to each column of the master's primary key.
This is the reverse of the way you might do
an object model -- one thing to possibly
get turned around about. (Also, in principle
we could use any unique key of the master, but
let's leave that aside for the moment.)
So for each column in the master's primary
key we need to specify the name of the
corresponding column in the detail table.
Concretely this is done in the <key-fields>
part of the fle. I would
guess here that activityId is the primary
key of the master, and from that standpoint
you have specified this superfluous year column.
I would further guess that (activityId, year)
is the primary key of the detail table, and from
that standpoint you've gotten turned around
about whether to specify the primary key of
the master or of the detail table.
The latter guess points to the second likely
problem. It looks like you're using the common
idiom in which the detail table has the master's
primary key as part of its composite primary
key. Or to put that another way the foreign
key field is part of the primary key. Problem
is jBoss doesn't support this. But since this
problem comes up a lot there is a (very new)
patch for it.
Let me know if I've got this right -- I'd rather
be publicly chagrined than be totally off-track
but not know it.
I'm having this problem too. The "One" table has one column as the primary key. The "Many" table has a foreign key of the "One" table and another column representing a composite key. JBoss does not seem to handle this relational design well. For example, with cascade deletes it sets to null the foreign key field in the "Many" table. Because I would like this column not null, I have problems.
> I'm having this problem too. The "One" table has one
> column as the primary key. The "Many" table has a
> foreign key of the "One" table and another column
> representing a composite key.
If I understand you correctly, you are trying to implement a true identifying relationship in the physical database. I tend to use another approach that yields the same results, but does not require the FK in the child table to migrate to the PK. See below.
> JBoss does not seem to
> handle this relational design well. For example,
> with cascade deletes it sets to null the foreign key
> field in the "Many" table.
Yes, JBoss CMP has a hangup in that it does not allow FKs to be 'not null'.
When implementing identifying relationships in the physical database, I never migrate the FK to become part of the PK. I prefer to stick to non-composite surrogate PKs as they perform better (I do use composite PKs in certain situations when I need to implement inheritance). I then simply constrain the FK to be 'not null'. Once JBoss CMP is rectified to handle 'not null' FKs, I would recommend this approach in implementing identifying relationships.
> Because I would like this
> column not null, I have problems.
Yea I agree with you. But I'm not the DBA. I have to adapt my ejb's to an existing database structure.
Overall JBoss rocks, and combined with the rapid open source app tool Xdoclet I'm extremely impressed.
The database folks have told me that the "Many" table that has a composite key (which includes a column that is a foreign key) does not exist without the "One" parent table. Therefore philisophically a child does not exist on it's own and should be aware of it's parent. Hence the composite key in the "Many" table has two columns, one of which is a foreign key. Because the foreign key is part of the composite key, I can't use JBoss to manage relationships because JBoss set's foreign keys to null for various transactions. Any JBoss "core" folks have any comments and is there anything in the works to remedy this problem.
I am not sure if it is the same problem but I had the same message and the reason for it was that my
ejb-jar file did not have a <primkey-field> for my primary key field in my master entity.
So I guess if you put <primkey-field>activityId</primkey-field> in the Activity bean's descriptor, it might help your problem.
The activityid and year column form the primary key in the master table, and these fields exist in the detail table which make up the foreign key.
My detail table doesn't have a primary key.
In reading other posts in the forum it seems composite pk's are a problem. Unfortunately I am trying to model the ejb's on top of an existing database, so changing the structure of the database is not painless.
Does this patch you mentioned handle composite pk's? I just downloaded 3.2b3, does this contain the patch mentioned?
thanks for the help,
The patch (actually, the change note) is described here
or with slightly less detail
I can't tell from the note whether it supports composite keys or not. The update is for 3.2, but I don't know if
it's been incorporated yet or not.
Could anybody please confirm if current JBoss (v3.0.4) supports this?
I have the problem described in previous message in this forum. In my Newsletter <-> NewsletterSubscribers situation, does this mean that, in the subscriber EJB, making the CMP field "newsletter" and the CMR field also "newsletter" have that exact name (now the CMP is newsletterid and the CMR newsletter) will make it work?
This does not work in 3.0.4 for the creation of tables. When you have an identical cmp and cmr field, JBoss generates a sql create which tries to include two columns of the same name. I do not know if, once the columns are created it will do the right thing with other functions.