« Rome Badge
Atom + Jena »

Rolling with Castor

I’ve begun off-hours work on an experimental project to persist ROME beans into a back-end database. I started with straight JDBC connections and my own xml mapping structure, but Robert Cooper of FeedPod fame turned me onto Castor. After getting over my initial misgivings, I quickly warmed to the suggestion.

Myth: Castor is dead. Fact: A review of the Castor website shows a lot of activity and new releases in 2004.

There are various resources out there on getting up to speed with Castor… some better than others. Here is my suggested reading list for anyone investigating Castor JDO on their own:

  1. Using Castor JDO
  2. Mapping Castor Objects to a Database with Castor JDO
  3. Cultivating your relationship with Castor JDO
  4. Data Access Object (DAO) Design Pattern

This last link is helpful to understand some of the more elegant ways to handle persisting/retrieving objects through any mechanism, Castor included.

This entry was posted on Tuesday, February 1st, 2005 at 09:03 and is filed under syndication, rome. You can follow any responses to this entry through the RSS 2.0 feed. Both comments and pings are currently closed.

4 Responses to “Rolling with Castor”

  1. Robert Cooper Says:
    February 1st, 2005 at 15:38

    Thanks for the linkage :) , alas, the feedpod.screaming-penguin.com site is going to die soon, though. The http://feedpod.dev.java.net is the new official home.

    Note from Woody: Noted and updated.

  2. Robert Cooper Says:
    February 1st, 2005 at 15:44

    Another thing you might want to add to your link collection, is a good OQL tutorial.

    http://www.cis.upenn.edu/~cis550/oql.pdf

    is about the best one I have found, sorry it’s a PDF. Castor has a couple of caveats in it’s OQL implementation that make complex queries problematic. You can use a direct SQL query and have Castor pick up the map for really complex stuff, but it comes with the caveat that you have to select the fields in the same order they appear in your Mappings file. I have a class here somewhere that will scan your mappings file and build a field list for a select. I will try and dig it up.

  3. Robert Cooper Says:
    February 1st, 2005 at 15:51

    While I am spamming your comments, one thing that has always pissed me off about that DAO patterns document:
    // Abstract class DAO Factory
    public abstract class DAOFactory {

    // List of DAO types supported by the factory
    public static final int CLOUDSCAPE = 1;
    public static final int ORACLE = 2;
    public static final int SYBASE = 3;
    ...

    // There will be a method for each DAO that can be
    // created. The concrete factories will have to
    // implement these methods.
    public abstract CustomerDAO getCustomerDAO();
    public abstract AccountDAO getAccountDAO();
    public abstract OrderDAO getOrderDAO();
    ...

    public static DAOFactory getDAOFactory(
    int whichFactory) {

    switch (whichFactory) {
    case CLOUDSCAPE:
    return new CloudscapeDAOFactory();
    case ORACLE :
    return new OracleDAOFactory();
    case SYBASE :
    return new SybaseDAOFactory();
    ...
    default :
    return null;
    }
    }
    }

    I would smack around anyone I knew who wrote a factory like that. We have Class.forName( “foo.Factory” ).newInstance() for a reason! It’s so you don’t have to go back and change the DAOFactory every time you implement a new bloody factory class!

  4. Woody Says:
    February 1st, 2005 at 16:01

    Funny, you landed on the one thing that puzzled me most about that recommendation.

    The only justification I could imagine would be to guarantee that only “approved” factories are handed out. With your flexible Class.forName() approach, you’re opening the door to instantiating a clandestine, terrorist factory that reads your bank account numbers and sends you naughty email.

    The Virus Factory Pattern…. keep your eyes open.