Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 31 Next »

Home page: http://castor.codehaus.org


Castor XML related projects

On Castor XML we are currently working to support JAXB2 and to introduce new features. Below packages can be seen as separate units of works that can and shall be designed and developed individually.

Title

StAX for un-/marshalling

Keywords

Java, XML, StAX

Description

Currently Castor uses SAX for unmarshalling, and offers partial support for using StaX to selectively stream XML 'fragments' into Castor's Unamrshaller. The idea of this project is add support for StAX for unmarshalling within the XML data binding framework itself. As a result, it should be possible to switch between SAX and StAX. As such, it will be necessary to separate concerns in Castor XML and to refactor the MarshalHandler so that XML handling and object instantiation are addressed at separate layers.

Mentor(s)

Werner Guttmann (wguttmn AT codehaus DOT org)


Castor JDO related projects

On Castor JDO we currently improve our current codebase, add new features and make Castor conform to JPA specification.

Title

Refactor transformation of OQL to SQL queries

Keywords

Java, OQL, JDBC, SQL, 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.
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. 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.
We like Castor to be able to execute EJB QL queries as specified by JPA specification. The implementation has to support at least the same queries that are supported by the current query language of Castor. The specification can be downlaoded from http://jcp.org/aboutJava/communityprocess/pr/jsr317/index.html.

Mentor(s)

Ralf Joachim (rjoachim AT codehaus DOT org)


Title

Refactor strategy to load entities from database

Keywords

Java, ????

Description

????

Mentor(s)

Ralf Joachim (rjoachim AT codehaus DOT org)


Title

Refactor transformation between properties of entities to columns of tables

Keywords

Java, ????

Description

????

Mentor(s)

Ralf Joachim (rjoachim AT codehaus DOT org)


Title

Refactor entity locking

Keywords

Java, ????

Description

????

Mentor(s)

Ralf Joachim (rjoachim 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.3 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)


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:

  • Improve mapping to allow specification of additional information needed by ddlgen
  • Use Class- and FieldDescriptor's instead of directly accessing classes of org.exolab.castor.mapping.xml classes
  • Replace PrintStream and StringBuffer by a Writer implementation
  • Execute script on database engine
  • Extract ordering strategies of DDL statements into an interface with 2 implementations
  • Add a advanced ordering strategy for DDL statements that takes relations into account
  • Merge multiple mappings to same table
  • Resolve collisions of name/many-key definitions at generation of n:m relation tables
  • Generate lookup table for HIGH-LOW keygenerator
  • Use Castor's standard configuration mechanism instead of the specific one from DDL Generator

Mentor(s)

Ralf Joachim (rjoachim AT codehaus DOT org)


More project ideas probably will be added soon.

  • No labels