[server] Thumbs Up To JPA [WAS Re: svn commit: r730371...]

[Robert Burrell Donkin <ro...@gmail.com>]

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,  <rd...@apache.org> 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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org