Hi All,

I am trying to design a query service for my system. Let me give you a background for my problem.

I have a centralized data base which manages identity information (Identity management) for the users (customers). This centralized data is used by many products of my company to create and read information.

Most of the products use this data for read only purpose. Currently we have a framework which generates the SQL query depending upon the user provided criteria and return attributes but it has its own limitations.

I am planning to use hibernate HQL or criteria APIs for this. I think if I'll allow them to fire HQL or use Criteria API directly it'll tightly couple them with the DB, which will affect the backward compatibility in case of any DB change. And if I build an abstraction layer around HQL or criteria API, I'll not be able to use the power of HQL or criteria API.

I know I am trying to use hibernate in a different way, but I'll be thankful for any ideas or suggestions.

Thanks
AtulD

Building an abstraction layer around Criteria is easy. Easier than HQL, anyway. And you don't need to worry about losing any power: it's your abstraction layer, you can put anything you want into it. Start with the basics, and add featues only when you need them.

Have your abstraction object contain a DetachedCriteria object. Once you have a complete DetachedCriteria object, using it in your Hibernate-aware code is easy.

Hi Tenwit,

Thanks a lot for the responce. I have decided to use Hibernate Criteria API. But I am not able to figure out that how I'll maintain the backward compatibility. My database changes quite frequently like (Name changes from name to first name last name or moving some column from one table to another table or making a property from single to multi value or dropping a column or table because of functionality change). I know these kinds of changes should not happen but our system is evolving to include new products and there are changes for existing products.

In this scenario it is very difficult for me to maintain backward compatibility for the existing products who are using the system.

Any design ideas in this regard will be helpful. Thanks in advance.

Thanks
AtulD

Create your search object: to make it distinct from DetachedCriteria, I'll call it SearchObject. It extends DetachedCriteria, or at least includes a private DetachedCriteria instance. Importantly, it includes all your application-specific methods like "compareName(String first, String last)", or "beforeDate(Date date)". These methods know about hibernate property names, when to use Restrictions.eq versus Restrictions.ilike, etc. And if you ever abandon Hibernate, you still have your SearchObject with its application-specific methods: you can convert it to whatever new technology you're using instead of Hibernate.