Castor Ideas

Title

StAX Annotations for marshallingCastor XML mapping

Keywords

Java, XML, StAX Annotations

Description

Currently Castor XML uses SAX for un-/marshalling, and offers partial support for using StaX to selectively stream XML 'fragments' into Castor's Unmarshaller. At the marshalling side of things, there's currently no support for StAX. an XML-based mapping file to specify the XML data binding contract. The idea of this project is add support for StAX for marshalling to the XML data binding framework natively. 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 Castor internals.

Mentor(s)

Werner Guttmann (wguttmn AT codehaus DOT org)

Title

Improve Sprig ORM support for Castor JDO

Keywords

Java, JDO, Spring ORM

Description

Currently the Castor project offers integration into Spring ORM through a separate Spring ORM provider. The idea of this project is to reassess the current offering in terms of feature completeness and to (re) evaluate the interfacing to Castor JDO. Based on these findings, the current code (e.g. CastorTemplate) will be improved and refactored (where applicable), and Castor JDO will be extended to allow injection of e.g. JDBC DataSources.

Mentor(s)

Werner Guttmann (wguttmn AT codehaus DOT org)

Title

Refactor transformation of OQL to SQL queries

Keywords

Java, OQL, JDBC, SQL, Junit

Description

In a former GSoC we have implemented a class hierarchy to represent OQL queries. With this project parsers for CastorQL and EJBQL have also been implemented that transform query strings into this class hierarchy. What still is missing is the transformation of this class hierarchy into SQL queries. To achive this goal OQLQueryImpl and QueryResult have to be refactored.

Mentor(s)

Ralf Joachim (rjoachim AT codehaus DOT org)

Title

Inheritance

Keywords

Java, SQL, XML, JUnit

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, JUnit

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 XML specific annotations throughout the framework so that these can used as a full replacement for mapping files. On a high level, this involves defining a set of annotations, implementing the annotation processing and integrate the output of this processing with Castor XML so that class resolution has a knowledge about this new source of binding infromation.

Mentor(s)

Werner Guttmann (wguttmn AT codehaus DOT org)