Castor JDO related projects

The JDO related projects described below are our ideas of what could be interesting for you. If you have other ideas or like to address some issues from issue management system (jira) you are also welcome. Just contact us to discuss if they fit into our plans for the future before you spend a lot of time to write a proposal.

Title

Improve JDO test framework

Keywords

Java, JUnit

Description

Because of some limitations of our old test framework we have implemented a new one based on JUnit. Some tests that could not be executed with our old framework have already been implemented with the new one but most of our test cases still can only be executed with the old one. The major task of this project is to migrate the tests from the old to the new framework. Beside the migration we like each test to setup the database records required on his own. At the moment this is done by the DDL script to setup the tables for some of our tests.
To be able to execute the tests with bamboo (the continous build system at codehaus), the tests should be executed against an embedded derby database by default. This requires that a preconfigured derby database with all tables needed gets started up when executing the tests.
Being able to setup the required tables at an empty database using SQL scripts generated by Castor's DDL Generator would be a nice add on. Having said that this requires someone else working at the project to improve Castor DDL Generator in parallel.

Mentor(s)

Ralf Joachim (rjoachim AT codehaus DOT org)

BackupMentor(s)

Werner Guttmann (wguttmn AT codehaus DOT org)

Title

Improve Castor DDL Generator

Keywords

Java, SQL, XML

Description

At the moment DDL Generator is able to generate almost all SQL schema objects for various database engines into a file from Castor mapping. But there is still some space for improvements like:

Use Castor's standard configuration mechanism instead of the specific one from DDL Generator

Mentor(s)

Ralf Joachim (rjoachim AT codehaus DOT org)

BackupMentor(s)

Werner Guttmann (wguttmn AT codehaus DOT org)

Title

Refactor generation of SQL queries

Keywords

Java, JDBC, SQL

Description

The object query language that Castor supports today is quite limited and has to be improved in some ways. On the other hand this task is very difficult as the codebase of the query engine is a bit crapy and split over many classes in different packages. To overcome this situation we plan to approach the problem from 2 sides. One is to refactor the generation of SQL queries at the current codebase. We think that this should make it much easier to replace the OQL to SQL transformation and plugin a new object query language later on. The implementation of the new OQL from scratch is the other side to approach a solution.

At the moment a SQL query is created by concatenating strings at various places. At each of this places the table and column names as well as the joins needed is extracted from descriptor classes or directly from mapping. To get the column values out of the result of the JDBC query, the same information is extracted from decriptors and mapping for the second time. In the past we had quite some problems to keep the sequnce of columns in the SQL in sync with the sequence expected in the query result.
The idee for the refactoring is to move the the creation of the SQL string and the access of the values of the query result into a set of new classes. Let's call them SQL query objects. When a query is to be created, we construct a hierarchy of instances of this classes. At the end we simply call toString() at the root of the hierarchy to get the SQL query string. To get the values out of the query result, we consult the same class hierarchy again. This way we omit any problems with the sequence of columns.
Instead of using both, descriptors and mapping, it will be apreciated to use only descriptors as a single source of information. Having said that this will require to add the information only available in mapping to the descriptors. Beside the refacoring in general, the support of different SQL dialects is a challange at this project.

Mentor(s)

Ralf Joachim (rjoachim AT codehaus DOT org)

BackupMentor(s)

Werner Guttmann (wguttmn AT codehaus DOT org)

Title

OQL query engine

Keywords

Java, OQL, Junit

Description

The object query language that Castor supports today is quite limited and has to be improved in some ways. On the other hand this task is very difficult as the codebase of the query engine is a bit crapy and split over many classes in different packages. To overcome this situation we plan to approach the problem from 2 sides. One is to refactor the generation of SQL queries at the current codebase. We think that this should make it much easier to replace the OQL to SQL transformation and plugin a new object query language later on. The implementation of the new OQL from scratch is the other side to approach a solution.

For the new object query language we like to conform to EJB QL specified at persistence part of EJB 3.0 specification. The specification can be downlaoded from http://jcp.org/aboutJava/communityprocess/final/jsr220/index.html.
As it will be quite difficult to implement the whole language at once, the first task will be to define a roadmap for the implementation. The roadmap should contain a list of features as well as the BNF for each step of the implementation. Based on this roadmap we intend to define your targets for the project together with you.
The base idea for the implementation is the create a class for every element of the language. This will enable us to represent a query with a hierarchy of objects of these classes. By calling toString() at the root of the hierarchy a string representation of the query can be generated. For the opposit direction, to transfor a query string into a class hierarchy, you generate a parser using a parser generator like JavaCC or antlr. Apart of the featurs you have to implement junit tests to verify that your implementation works as expected.
To limit the scope of this project, we do not expect you to implement the full specification nor to integrate the new object query language into Castor. This will be done later on at a follow up project. We only expect you to implement the query string to object transformation and vice versa for a subset of the language.

Mentor(s)

Ralf Joachim (rjoachim AT codehaus DOT org)

BackupMentor(s)

Werner Guttmann (wguttmn AT codehaus DOT org)

Title

Inheritance

Keywords

Java, SQL, XML

Description

To persist polymorpic objects, a hierarchy of objects that extend each other, one would want to choose between 3 different strategies:

a table for every class of the hierarchy

a table for every concrete class of the hierarchy

one table for all classes
As of version 1.2 Castor supports only the first one (table per class). With this strategy Castor can evaluate the class of an object by looking in which of the tables an entry for the object to be loaded exists. While this would also be possible for the table per concrete class strategy, will the table per class hierarchy require a column that holds information to destinguish the class of the object.
Our plan to improve the inheritance startegies Castor supports is, to move the logic that decides of which class an object loaded is into a new Disciminator class. Having said that this refactoring will be quite difficult and challenging.
To add more strategies next, you will need to extend our mapping to be able to specify the strategy and other information required for them. If you have managed this, adding one or both of the missing strategies should be quite easy for you.

Mentor(s)

Ralf Joachim (rjoachim AT codehaus DOT org)

BackupMentor(s)

Werner Guttmann (wguttmn AT codehaus DOT org)

Documentation

As all open source projects, we'd welcome any support to enhance/restructure the projects documentation. This includes
the main HTML documentation, as well as adding HOW TOs, etc.