Null CMR fields broken in 3.2.0 RC2?

[cschmidt]

Hey there,

I figured I would try updating from 3.2.0 RC1 to RC2. I have an existing EJB app that works fine on RC1 (on top of MySQL 4.x). However, when running on RC2, I get the following exception after creating a CMP EJB with a many-to-one relationship, where the relationship field is set to null:

TransactionRolledbackLocalException, causedBy:
javax.ejb.NoSuchObjectLocalException: Entity not found: primaryKey=[.0.]


In RC1, whenever a CMR field on the one-side of the relationship is NULL, the foreign key field is set to a null value. However, in RC2, it's set to "0"! In the following queries captured from the MySQL log, the alwaysSendListID value should be NULL, but it gets set to 0 instead:

INSERT INTO Campaigns (dateCreated, description, alwaysSendListID, qaListID) VALUES (null, null, null, null)
UPDATE Campaigns SET description='Newsletter', alwaysSendListID=0, qaListID=0 WHERE campaignID=1
UPDATE Campaigns SET qaListID=3 WHERE campaignID=1


In RC1, things worked like this:

INSERT INTO Campaigns (dateCreated, description, qaListID, alwaysSendListID) VALUES (null, null, null, null)
UPDATE Campaigns SET description='test 2' WHERE campaignID=5
UPDATE Campaigns SET qaListID=2 WHERE campaignID=5


Notice that in the UPDATE statement following the INSERT, RC1 does *not* include the foreign key values, whereas RC2 includes 0 values. This looks broken to me...

- Carl

[tommyg]

That's a good thing for people like me. Sorry! But I have a legacy database, like a lot of people, in which the foreign key can never be set to null. So it appears JBoss fills the field temporarely with a dummy value, to appease folks like myself.
Hopefully for both of us, there is a way to control the persistence logic.

[cschmidt]

I can see your point. For me (creating a new schema), I don't really care as long as it works!

The EJB 2.0 spec doesn't place any restrictions on how null relationship fields are mapped to the database (section 10.3.11). Which means it's up to the container provider. A null relationship field could EITHER be represented as a SQL NULL, OR as a fixed key value that will not exist (i.e. 0, -1, etc.). To handle mapping to existing schemas, this really should be configurable.

I've been digging a little through the source code, but it takes a little doing to understand what's going on. Hoping someone with an *authoritative* opinion will weigh in here soon... ;-)

- Carl

[cschmidt]

Also broken in 3.2.0 RC3. I reported this as a bug on SourceForge:

http://sourceforge.net/tracker/index.php?func=detail&aid=698235&group_id=22866&atid=376685

And supplied a nice little test case. Is noone else running into this? Just a little further detail, I've narrowed it down a bit. If you supply a null value for a CMR field at *create* time, then things will break. If you initially supply a non-null CMR value, and then in another transaction set the CMR field to null, then it works fine.

- Carl

[cschmidt]

<not-on-drugs>
Wierd, I posted this but the post didn't show up, even though the topic bumped to the top of the list. Let's try again...
</not-on-drugs>

Also broken in 3.2.0 RC3. I reported this as a bug on SourceForge:

http://sourceforge.net/tracker/index.php?func=detail&aid=698235&group_id=22866&atid=376685

And supplied a nice little test case. Is noone else running into this? Just a little further detail, I've narrowed it down a bit. If you supply a null value for a CMR field at *create* time, then things will break. If you initially supply a non-null CMR value, and then in another transaction set the CMR field to null, then it works fine.

- Carl

[gturner]

Is this fixed?

I just upgraded an old app from 3.0.8 to 3.2.2RC3 and am having the same problem.

Funny thing is that the artifical zero isn't actually updated on the foreign key column. I'm using Oracle9i.