Re: AW: [Objectbridge-developers] optional relationships

[Dirk O. <di...@xa...>]

Mahler Thomas wrote:
> 
> Hi  Dirk,

Hi,

> There is sample code for reflexive Joins in package test.ojb.broker have a
> look at classes Tree and TreeGroup and there respective mappings.
> The Junit test for this resides in class TreeTest.
> You will see that the root nodes of the trees don't have entries for a
> parentId while the child nodes have.
> You find the respective mappings in the repository.xml file.

Well I can't get the Tree/TreeGroup example to run, it fails with
the following exception:

java.sql.SQLException: Invalid parameter number: 1
[...]
but that just as a side note.

After digging around in the testcase, however I find that you never
encounter the case that I have described above mainly because the Tree
instance will be created by the testcase. When creating a new Tree
instance, the parentId is zero ( (int)0 ). When it's saved to the
database, the db will happily accept zero and return it later when the
test queries all of the Tree instances.

In my test I filled the database "by hand" and ran into this error.

The fact that the foreign key defaults to zero is not formally correct,
though. Note that the foreign key has a value assigned: it's zeor which
is not the same as NULL ( (int)null ). I would not want to impose any
restrictions on primary key values (or foreign key values) just to make
the framework do it's work (although this is the workaround I have
chosen for now). Just imagine someone else using the same database with
a different tool/persistence framework.

In the case where you have a database that allows for null values for
the parentId, you will run into exactly the problem, it's in
JdbcAccess::readObjectFromResultSet(), either in line 317 or in line
331, depending on your class having a multi-arg constructor or not.

There, JdbcAccess tries to assign (int)null to an instance variable of
the value class which fails because java.lang.reflect just cannot do
this.

> I don't see how the formal usage of a foreign key in the database schema
> could cause problems?!

Me neither, maybe it's just a different interpretation of the term
foreign key?

-dirk