AW: AW: [Objectbridge-developers] optional relationships

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

Hi Dirk,

> -----Urspr=FCngliche Nachricht-----
> Von: Dirk Olmes [mailto:di...@xa...]
> Gesendet: Montag, 13. August 2001 18:52
> An: Mahler Thomas; obj...@li...
> Betreff: Re: AW: [Objectbridge-developers] optional relationships
>=20
>=20
> Mahler Thomas wrote:
> >=20
> > Hi  Dirk,
>=20
> Hi,
>=20
> > There is sample code for reflexive Joins in package=20
> 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=20
> entries for a
> > parentId while the child nodes have.
> > You find the respective mappings in the repository.xml file.
>=20
> Well I can't get the Tree/TreeGroup example to run, it fails with
> the following exception:
>=20
> 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 JUnit =
Testsuite and
runs without errors with "build.sh junit" (or "build junit" under =
Windows)
on Linux and windows.

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

> 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.
>=20
> In my test I filled the database "by hand" and ran into this error.
>=20
> The fact that the foreign key defaults to zero is not=20
> formally correct,
> though. Note that the foreign key has a value assigned: it's=20
> 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)=20
> 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=20
> database with
> a different tool/persistence framework.
>=20

Yes you are right, this is really a bug!

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

I changed line 331 as follows:
// if val =3D=3D null and the field-type is primitive do NOT set the =
attribute!
if ((val !=3D 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.


cheers,

Thomas

P.S.: Apropos PING: ist das nicht die Private Internet Nutzer Gruppe =
aus dem
Raum Dortmund? Dann sind wir r=E4umlich nicht soweit auseinander (Ich =
wohne in
Essen)...

> > I don't see how the formal usage of a foreign key in the=20
> database schema
> > could cause problems?!
>=20
> Me neither, maybe it's just a different interpretation of the term
> foreign key?
>=20
> -dirk
>=20