i've completed the first milestone of the JPA port. there are some remaining issues but it's mostly working now. the architecture needs work: the transaction structure isn't right ATM - it's better to adopt a structure which can be more easily reused either standalone or in a manager environment.
once i'd sorted out the code in torque clone, porting to OpenJPA proved straightforward (taking less than a day). i was impressed :-) i know that there has been discussion in the past about OM frameworks (and whether they're worthwhile at all) but IMO JPA is a very good solution which - when coupled with the right design - should be good enough to replace the direct SQL and avalon. some highlights (picked out from the code i've just committed) here's an annotated persistent POJO On Wed, Dec 31, 2008 at 10:44 AM, <[email protected]> wrote: > Added: > james/protocols/imap/trunk/jpa/src/main/java/org/apache/james/imap/jpa/om/Message.java ... > +...@entity > +...@idclass(Message.MessageId.class) > +...@namedqueries({ > + @NamedQuery(name="resetRecentMessages", > + query="UPDATE Message message SET message.recent = FALSE WHERE > message.mailboxId = :idParam AND message.recent = FALSE"), > + @NamedQuery(name="findRecentMessagesInMailbox", > + query="SELECT message FROM Message message WHERE > message.mailboxId = :idParam AND message.recent = TRUE"), > + @NamedQuery(name="findUnseenMessagesInMailboxOrderByUid", > + query="SELECT message FROM Message message WHERE > message.mailboxId = :idParam AND message.seen = FALSE ORDER BY message.uid > ASC"), JQL (JPA Query Language) is very close to SQL. i see this as key advantage. one of the strong arguments about avoiding ORMs is that most James developers know more than enough SQL to code by hand. a key disadvantage with SQL is having to maintain DB ports. i think JQL is sufficiently SQL-like to be very easy to learn for anyone with good SQL (it took me about an hour to learn enough for IMAP) but the JPA maintainers have the chore of porting to SQL dialects. ATM OpenJPA actively supports 18 databases (including all the majors). JQL supports most powerful SQL operations including bulk updates and deletes. torque required custom SQL but all IMAP needed could be done directly in JQL in JPA 1. another strong argument against ORMs has been that serious mail servers cannot avoid using powerful operations just because the ORM does not support them. JQL may well be powerful enough. one or two ad-hoc queries are constructed on the fly but where possible, i use NamedQuery's. these map naturally to parameterised queries in SQL. i think it's expressive to keep as many queries as possible with the POJO (though it's not required). NamedQueries are accessed by name. providing that the names are carefully chosen, this leads to expressive code. ... JPA prefers field injection marked by annotations > +public class Message { > + /** The value for the mailboxId field */ > + @Id private long mailboxId; > + > + /** The value for the uid field */ > + @Id private long uid; > + > + /** The value for the internalDate field */ > + @Basic(optional=false) private Date internalDate; ... > + /** Headers for this message */ > + @OneToMany(cascade = CascadeType.ALL, fetch=FetchType.LAZY) private > List<Header> headers; this seems expressive and the basics are easy to learn. the table structure generated seems to require tuning with more complex annotations but the idea is clear (i think). the general approach is the JPA adopts reasonable (though not always intuitive) defaults but annotations are available for tuning (which is usually required). transactions and caching can be tricky in some cases - robert --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
