What I'd like to see in Java Persistence

Category: Java

1:38 AM, Wed, Feb 20 2008

In this post, I'm going to discuss the persistence aspects of EJB 3.0, and what I would like to see in EJB 3.1 or some future version. I love EJB 3 persistence but that doesn't mean I don't want more.

EJB 3.0 implements JSR 220. EJB 3.0 is an object-relational mapping (ORM) system for Java, combining features of Hibernate, JDO and TopLink ORM systems. The Java Community Process is working on defining the next features with JSR 318. Here are some ideas I would like to see:

• Hibernate-style criteria queries: EJB-QL is a great improvement over SQL for object-oriented developers and languages, but, like SQL, EJB-QL is not an object-oriented way of thinking about queries. Criteria queries are object oriented. They make it easy to conditionally add conditions to the "where" part of the query. They also make it easier to catch query errors at compile time instead of run-time. It's almost certain that a future version of EJB persistence will support criteria queries.
• Collections of simple types: I'd like to be able to have a Set of strings, or an array of ints, or a List of Integers in my entity classes, and have it Just Work.
• Ability to serialize the entire data set, to XML: I'd like to be able to have the EntityManager automatically create an XML representation of all the data that it manages. This would be like a database dump, except in XML, and not dependent on any type of SQL. Of course, if the EntityManager is able to automatically map objects and define tables and generate SQL statements (which of course is what it does) it shouldn't be a big step to also represent all those tables as XML. There are two obvious uses for this functionality: one is to back up the data. The other is to move the data from one database to another. What if we launch the system using MySQL and, after 10,000 users have signed up, we want to switch to Postgres? As it is now, we have to do some painful by-hand conversion, which will be complicated and might not work correctly. The EntityManager should be able to automate the creation of a portable, XML-format representation of its managed objects. I haven't seen references to this type of functionality; I would like to see it happen.
• A standard way of handling attachments and large objects: What site today doesn't have to manage video, image and sound file uploads? Right now our options are to either handle them in the DB, as large objects (LOBs), or write our own code for putting them in the file system. LOBs can work, but are not an efficient use of the database. Writing our own code for dealing with files, MIME types and directories is tedious. It would be great if there were a standard for this, and Enterprise Java containers would provide this "attachment persistence" as a service.

That's my wishlist for now. None of these are big architectural changes. I'm sure that criteria queries are on their way. I hope the others will make it in also.