[Dev] New support for Hibernate XML mapping files

[Brett Wooldridge]

We're not using NamedQueries yet as we haven't had a case that needed them.  But I'm not overly concerned about burying queries in the code because well, queries are already buried in the code ... no different than:

        Criteria criteria = session.createCriteria(ZDeviceLite.class)                                   .add(Restrictions.eq( ATTR_MAKE, make))
                                   .add(Restrictions.like(ATTR_MODEL, trimModel, MatchMode.ANYWHERE));                                   .setFirstResult(pageData.getOffset()).                                   setMaxResults(pageData.getPageSize());
Even though ZipTie NCCM runs across three databases (Derby, MySQL, PostgreSQL), we have so far avoided any DB-specific code.

When it comes to what is gained or not gained, at this point is purely an academic discussion.  But I am personally a fan of standardized APIs.  The fact that we used pure JTA allowed us to easily switch from one transaction provider (ObjectWeb JTOM) to another (Bitronix) with very little impact on the code - the only impact was where I had mistakenly broken encapusalation in packaging.  Having the ZAP expose a JPA provider would allow ZipTie or anyone else using ZAP to easily select TopLink, for example, as their JPA rather than Hibernate.  TopLink/now EclipseLink (http://www.eclipse.org/eclipselink/), JPOX (http://www.jpox.org/), and Apache OpenJPA (http://openjpa.apache.org/) are all becoming increasingly popular and robust implementations of the JPA spec.

I estimate the implementation of JPA in ZAP to be about 3-days, but the cutover of existing ZipTie code would take about one week due to the reasons you mentioned (use of Session being the primary).  I don't plan to do anything in that respect until after the Summer release of ZipTie.

My thought was to have a org.ziptie.zap.jpa bundle exposing pure JPA APIs and registering the EntityManager as a service.  There is no reason that a hibernate bundle couldn't continue to register SessionFactory as a service.  It just that the ZipTie NCCM code itself would move to using EntityManager.  I'm not sure I would recommend mixing use of the two in the same application tho.  :-)

-Brett

On 5/8/08 3:15 AM, "Edmund Grossenbacher" <egrossenbacher at alterpoint.com> wrote:

I didn't realize you guys were already using NamedQueries.  They have a few drawbacks, but hey, none of these are killers:

1) annotations bury queries in Java code

2) SQL queries are harder to tailor to specific database syntax, which could be supportable with the XML approach by URL munging when the AnnotationConfiguration is built (albeit this would require more work than I have done to date)

3) queries that span multiple entities, return multiple entities, etc., end up apparently associated with an arbitrarily chosen Java class,

4) long query strings end up being split across multiple lines using string concatenation, resulting in harder to read, harder to edit queries.

But YMMV.  In any case, I *believe*, but have not verified, that if we switch to the EntityManager and it's associated createNamedQuery(...) methods we will still pick up these XML based queries.  I'm not 100% positive here, because the EJB-3 persistence spec defines its own XML configuration capability, including named query support.  I'm not sure how all of that works.

However, from my perspective, there is nothing to gain from the pure JPA approach except a bunch of refactoring.  So if possible, it would be *awesome* if you could maintain backwards compatibility with the zap.hibernate stuff, because currently I'm using Hiberate specific objects everywhere (the SessionFactory, Session, and Query objects that get scattered throughout code are all from the org.hibernate namespace.)

-ed

=====

Cool extension, and I don't mind the addition, but ZipTie developers take note that I prefer named query annotations on the class. They do the same thing and are associated with the object/table on which they operate. We don't have any pure DBA/SQL folks who eschew Java. :-)

@NamedQuery(

name="getAllOrder",

queryString="SELECT OBJECT(o) FROM CustomerOrder as o WHERE

o.customerId = :customerId")

And subsequently:

Query allOrders = em.createNamedQuery("getAllOrder");

allOrders.setParameter("customerId",customerId);

Collection <CustomerOrder> results = allOrders.getResultList(); return results;

Ed, I was planning to switch our org.ziptie.zap.hibernate to a pure JPA approach in the next two releases? Are these named queries in XML resource files Hibernate specific? If so, when I do the refactor, I'll be sure to encapsulate it in a new bundle (org.ziptie.zap.jpa) so that there is a graceful fork/non-conflicting branch.

-Brett

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ziptie.org/pipermail/dev/attachments/20080507/cfa5b497/attachment.html