db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Spräner, Carsten" <Carsten.Sprae...@viadee.de>
Subject Some (major) Bugs in OJB RC3/4
Date Mon, 18 Aug 2003 06:03:19 GMT
Hi all.

I thing we found some (major) bugs in OJB or we made something wrong in the usage of OJB.
We are using the new feature of mapping inheritance to different tables. This feature is new
in OJB RC3. Another Bug is in handling exceptions while there are locks in a locking table.
I listed the errors below. I attached a tgz-File to this mail where you find a test environment
for the Bugs. To run the test, follow these steps:

0. Excuse my English ;->
1. Extract the tgz to a location of your choice. It will create a new folder ojbTest. 
2. Copy all jars from the OJB-Environment/lib to the ojbTest/lib directory. Don't forget the
db-ojb-1.0.rc3.jar. If you use db-ojb-1.0.rc4.jar edit the class-path in the build.xml of
ojbTest and replace all name="this" to name="super" in the repository.xml files. 
3. Go to the ojbTest directory and run ant <testCase> where you can choose <testcase>
as generatorGap, ocot, aiot or opot. Each ant target sets up an environment for the test.
(It copies repository.xml and/or dbCreate.ddl to the ojbTest directory). 
4. The dbCreate.ddl is for db2-Environments. Start a db2 command environment. Create a test
database for the tests and connect to it:
   a: db2 create database test and edit the JCDs in all repository.xml files 
      so OJB can connect to your database.
   b: Do a "db2 connect to <test> user <x> using <y>" to connect to your

      database
   c: do a "db2 -tf dbCreate.ddl" to create the schema.
Steps a and b are only needed once. Step c is necessary after each set up of a new test environment.
It will create a new empty database. Running the script the first time gives a couple of errors
because the drop table statements do not find there tables.
5. Perform a "ant run" to start the test.

Step 1-4b are only needed once. You can repeat Step 4c and 5 again and again. The Test.java
uses the ODMG-API and is easy to understand. It creates several object nets and stores them
to the database with the ODMG API. 

Now here are the Bugs: 

1. (generatorGap)
It is not possible to map the following Situation:

  AGenarted <|-- A <|-- BGenerated <|-- B

You can test the behaviour by doing "ant generatorGap" and "ant run".

In this Situation the RepositoryHandler can not load the Repository because A is not the direct
superclass of B. But that should be no problem to OJB. I thing the algorithm should only check
if A is a superclass of B. Or the next mapped superclass of B is A.

2. Retrieving inheritance trees.
   (OneClassOneTable (ocot))
   (OnePathOneTable (opot))
   (AllInOneTable (aiot))
Try the following Situation: There is a Containerclass Container which references an abstract
Class Person. There are two derived classes of Person. NatuerlichePerson and Firma. Sorry
for the german names. In UML:
   
   Container --->  Person <|-+---NatuerlichePerson
                             |
                             +---Firma
OCOT:
The ocot-Example maps Person to a table PRS, NatuerlichePerson to a table PRSN and Firma to
a table FIRMA. Table FIRMA and PRSN references the PRS table via an FK attribute. The reference
is called this (or super in RC4).

>>>BUG?
Running this test the first time shows a NullPointerException. The real reason is that OJB
queries a PRS_NAME in the FIRMA-Table. But PRS_NAME is only in the PRS-Table. This query fails
because the broker implementation in Method getRsIteratorFromQuery tries to load FIRMA with
the same query as PERSON. But table FIRMA does not have the column for attribute name!!! IMHO
the method should perform the query on PRS as it does. But when it tries to load the extents
it has to analyze how the extension is implemented, create a query for the extension implementation
and perform this query for retreiving the extents. (See PersistenceBrokerImpl row 2328 to
2345 in RC3 of OJB. It is the same problem in RC4.) This Bug makes it impossible to perform
any query on an object hierarchy where the objects are mapped on different tables. It only
works if ALL attributes for queries are in all tables with the same value!
>>>BUG?
If you have a closer look to the output you see that the attributes of Firma are filled in
the retrieved Object but not the attributes of Person! Also there are two objects in the resulting
list?
>>>BUG?
Running the example a second time shows another Bug. Each run of Test creates a container
referencing to a NatuerlichePerson and another container referencing to a Firma. But if the
test looks up all Persons the number of NatuerlichePerson and Firma differs?

OPOT:
Now switch to the opot environment with "ant opot". The first run is OK. Everything works
fine. But after the second run the number of NatuerlichePerson is not equal to the number
of Firma?

AIOT:
This example works perfect!

3. (Exception during ODMG-Transaction)
Using database locking in ODMG-API: If you lock an Object to a transaction then OJB creates
an entry in the locking table with a special control connection. If an exception is thrown
in the operational code the broker does not use control connection for removing the locks
but the connection for doing the operational work. Thus when doing the rollBack all locks
are there again?!

Hope this can help you (and us :->)

Carsten Spräner



Mime
View raw message