Is there a good generic pattern for data store queries that hide vendor specific logic?

Question

I'm trying to find a good way to implement a generic search API in Java that will allow my users to search the backend repository without needing to know what that backend technology is, and so that if in the future we switch vendors I can reimplement the underlying logic without needing to recode the API. The repository underneath could be a relational database or a document store like SOLR, CouchDB, MongoDB, etc... It would need to support all the typical search requirements such as wildcards, ranges, bitwise operators, and so on.

Are there any standard ways of approaching this problem?

Would JPA be my best bet? Would it do everything I need it for, including non-relational databases?

Thanks in advance!

Answer 1

What you need is a ORM framework like Hibernate, if you go for JPA, you need to re-invent a lot of wheel.

using Hibernate you can write the business logic for searching the backend database or repository without vendor specific implementation, and if later you need to change the backend, you can do it without affecting your existing business code implementation.

I would advice you to check the hibernate documentation for further reference

Answer 2

The Spring Data umbrella of projects provides a nice DAO abstraction named CrudRepository . I believe most of the sub-projects ( JPA , MongoDB , etc.) provide some implementations of it.

Answer 3

JPA would be one of a number of implementations you would use to map your relational database to objects. It would not protect you from database changes.

I think you're looking for the DAO Pattern . What I'm doing is as follows:

1. Create an interface for each DAO
2. Create a higher level DAO implementation that simply calls my actual database specific implementation
3. Wire the higher level DAO implementation to the database specific implementation with Spring.

This way, no code anywhere touches database specific implementation. The connections are formed only in XML.

Answer 4

JPA is designed around RDBMS ... only. Using it for other types of datastores makes little sense since things likes its query language leak SQL syntax. JDO is designed for datastore agnoticity, and provides persistence to many datastores using its implementations such as DataNucleus, though not all of those that you mention.

Answer 5

JPA is designed around RDBMS, Hibernate is also designed for RDBMS. There are few implementations of JPA which support no-sql. Similar projects are built around hibernate to support no-sql databases. However the API itself is tuned for RDBMS.

Implemeting a DAO patterns would require you to write your own query api. Later extend the implementation when ever your data store changes.

JDO and DataNucleus is ground up designed for heterogeneous data stores. Already has support for a dozen stores ,plus RDBMS. Beauty is that the query api remains constant across the stores. JDO allows you to work with domain model and leave the storage details to implementations like DataNucleus.

Hence I suggest JDO api with datanucleus. The below link gives list data stores and f features already available in DataNucleus http://www.datanucleus.org/products/accessplatform_3_0/datastore_features.html