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 44 Next »

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


Basics

If you find any of the below proposals interesting and are thinking about submitting a proposal for GSoC 2011, please consider doing one of the following things first:

- Subscribe to the Castor dev mailing list, and make yourself heard, e.g. introduce yourself, talk about your ideas, engage with the committers, etc.

- Have a look at the Castor sources (via SVN), identify code relevant to the proposal you are interested it and show us your ideas by the means of a patch.

- Provide us with test case(s) that highlight your understanding of relevant functional parts of Castor XML/JDO/...

As a result of our mentor experience from 2009 and 2010, it will be very unlikely that we accept any proposal where the submitter has not engaged with us before.

Castor XML related projects

On Castor XML we are currently working to introduce STaX as additional XML parsing technology. Below packages can be seen as separate units of works that can and shall be designed and developed individually.

Title

StAX for marshalling

Keywords

Java, XML, StAX

Description

Currently Castor 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. 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)


Spring ORM support for Castor JDO related projects

Here, we are currently working to improve our offering and to extend the functionality offered. In addition, the current bean factories need to be refactored to allow e.g. injection of user-defined JDBC data sources (through e.g. DBCP).

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)


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

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 AT codehaus DOT org)


More project ideas probably will be added soon.

  • No labels