db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jakob Braeuchi <jbraeu...@gmx.ch>
Subject Re: Some (major) Bugs in OJB RC3/4
Date Thu, 21 Aug 2003 20:36:13 GMT
hi carsten ,

see inline

Spräner, Carsten wrote:

>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
>      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
>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).
>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 
ojb currently does not perform an automatic lookup of a field in the 
superclass. ths can be forced by using super. prefix (ie. 'super.name') 
but this would not solve your problem because it fails on the first 
query. it's quite tricky !


>are mapped on different tables. It only works if ALL attributes for queries are in all
tables with the same value!
>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?
>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?
>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?
>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
>To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
>For additional commands, e-mail: ojb-dev-help@db.apache.org

To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org

View raw message