AW: AW: [Objectbridge-developers] optional relationships

[Mahler T. <tho...@it...>]

Hi Dirk,

> -----Urspr=FCngliche Nachricht-----
> Von: Dirk Olmes [mailto:di...@xa...]
> Gesendet: Mittwoch, 15. August 2001 20:32
> An: Mahler Thomas
> Cc: obj...@li...
> Betreff: Re: AW: [Objectbridge-developers] optional relationships
>=20
>=20
> > > > There is sample code for reflexive Joins in package
> > > > test.ojb.broker have a
> > > > look at classes Tree and TreeGroup and there respective=20
> 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.
> > >
> >=20
> > How do you run it? This testcase is part of the standard=20
> JUnit Testsuite and
> > runs without errors with "build.sh junit" (or "build junit"=20
> under Windows)
> > on Linux and windows.
>=20
> I basically just run 'build junit' under Windows using the=20
> std. sun jdk
> 1.3. Maybe it's the JDK?
>=20
This is really strange! I've been running it on several NT and Linux =
Boxes
with a variety of VM's (incl. 1.3) and never had such an error.
Can you provide me with a full stack trace?

> > Or do you run it against a RDBMS other than instantDB?
>=20
> No, just the stock instantDB. I didn't bother to setup a=20
> different test
> database so far.
>=20
> > > In the case where you have a database that allows for=20
> null values for
> > > the parentId, you will run into exactly the problem, it's in
> > > JdbcAccess::readObjectFromResultSet(), either in line 317=20
> or in line
> > > 331, depending on your class having a multi-arg=20
> constructor or not.
> > >
> > > There, JdbcAccess tries to assign (int)null to an=20
> instance variable of
> > > the value class which fails because java.lang.reflect=20
> just cannot do
> > > this.
> > >
> >=20
> > I changed line 331 as follows:
> > // if val =3D=3D null and the field-type is primitive do NOT=20
> set the attribute!
> > if ((val !=3D null) || (!
> > fmd.getPersistentField().getDeclaringClass().isPrimitive()))
> >   fmd.getPersistentField().set(obj, conversion.sqlToJava(val, =
fmd));
> >=20
> > For line 317 it's not so easy:
> > The Constructor is defined in the Client Application thus=20
> it lies in the
> > responsibility of the Application developer. I have no=20
> chance to handle this
> > within OJB. IMO the developer has to handle this situation in the
> > constructor.
>=20
> Well, in this case we should either have good documentation on this
> behaviour.=20

Yes! I will add a special note on this in the "constructor missing" =
warning.

> 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 ...

I would prefer to stay with this single constructor for two reasons:
1. this (optional) constructor is already an intrusion into the clients
code. Having even more Constructors would increase the burden of the
application developer to be OJB-compliant.
2. To have all these constructors and to select the correct one =
according to
nulled primitive attributes would make the above piece of code much =
more
complicated.

-- Thomas
>=20
> -dirk
>=20