Re: AW: [Objectbridge-developers] optional relationships

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

> > > 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.
> >
> 
> How do you run it? This testcase is part of the standard JUnit Testsuite and
> runs without errors with "build.sh junit" (or "build junit" under Windows)
> on Linux and windows.

I basically just run 'build junit' under Windows using the std. sun jdk
1.3. Maybe it's the JDK?

> Or do you run it against a RDBMS other than instantDB?

No, just the stock instantDB. I didn't bother to setup a different test
database so far.

> > 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 changed line 331 as follows:
> // if val == null and the field-type is primitive do NOT set the attribute!
> if ((val != null) || (!
> fmd.getPersistentField().getDeclaringClass().isPrimitive()))
>   fmd.getPersistentField().set(obj, conversion.sqlToJava(val, fmd));
> 
> For line 317 it's not so easy:
> The Constructor is defined in the Client Application thus it lies in the
> responsibility of the Application developer. I have no chance to handle this
> within OJB. IMO the developer has to handle this situation in the
> constructor.

Well, in this case we should either have good documentation on this
behaviour. Maybe it's a better idea to start looking for a constructor
that doesn't include the parameter so as a developer I could implement
constructors for both cases. Then again, if you have more than one int
that could allow for NULL you would end up implementing lots of
constructors ...

-dirk