Background:
I've been using JPA lately, and I am very impressed by how easily I was able to produce a persistence layer for a reasonably large relational database project.
We use a lot of no-sql databases at my company, specifically column oriented ones. I have some questions about potentially using JPA for those databases:
Questions
Can JPA be used with NO-SQL databases? It stands to reason that if the framework can generate a query for a SQL database and map the results, then it probably could reasonably easily be tailored to generate a different kind of query and a different mapping, for say, querying Hadoop maybe?
If it's possible, are there any existing implementaitons of JPA that use things besides SQL?
Are there any good resources on implementing/extending JPA? I realize TSQL, PLSQL, etc. must all be specifically addressed in JPA, so there must be an extensibility mechanism we can manipulate.
There are various JPA implementations that support (the badly termed) "NoSQL" set of datastores. The most complete we've found to be DataNucleus which also provides the more suitable JDO API also. It supports MongoDB, Cassandra, HBase, AppEngine, LDAP, spreadsheets, Neo4j, and some others
As per your question i came across Hibernate OGM which stands for Hibernate Object Grid Mapper which provides JPA (java Persistence api)the support for the NoSQL solutions.
Hibernate OGM has the following capabilities : -
persists entities into a NoSQL
datastore specific native queries
full-text queries, using Hibernate Search as indexing engine
I haven't explore more on this framework OGM but looks very promising solution for your questions.
You can refer to the following URL to get more idea about the Hibernate OGM
http://hibernate.org/ogm/
Related
Given: There are multiple document-storage type NoSQL systems such as couchdb/base, mongodb, and aws-dynamodb (that can be both document and key-value). cross-check research: Document-storage based NoSQL systems can be found here: http://nosql-database.org/
When: Different nosql types (key-value, document store, etc) provide different benefits depending on what you are trying to implement. In the case of this question, document-storage of JSON content is desired, and evaluating a way to implement a good document-storage solution and test against different nosql databases is desired.
Question: Are there JVM-based frameworks (java, scala, groovy, whatever) that would provide an agnostic overlay similar to JPA and other ORM's that would allow implement-once code and test run against different nosql databases without rewirting the code (only change the configuration)?
Note: http://hibernate.org/ogm/ is one such example, but only lists one document-store based nosql database supported.
Spring Data currently has modules for Redis, MongoDB, Couchbase, DynamoDB and several other NoSQL databases.
The Hibernate OGM project currently supports MongoDB and Neo4j.
It looks like there is also JPA support for CouchBase, MongoDB and Google Cloud Datastore.
Hibernate seems to have what you are looking for.
I am currently working with MongoDB and Java and I have to decide if I use MongoDB's Driver, Morphia or Hibernate. Can anyone tell me what the advantages and disadvantages of Hibernate, MongoDB's Driver and Morphia are? And in what situation should I use which? A small example would also be nice, but is not really necessary.
Thanks!
Using a native driver :
It is always better if you have time to learn that driver.
Now coming to Mongo-Java-Driver it is quite simple to use. Initially terms like BasicDBObject, BSONObject may sound odd to you. After some time, you will find it comfortable. You can start with this quick tour to Mongo Java Driver.
Using ORM tool :
ORM tools like spring data, Kundera, Morphia use these native drivers internally. These makes it simple and comfortable to the user with some overhead in terms of performance sometimes.
So, it's up to you if you have time to explore go for Mongo-Java-Driver. otherwise, go for any ORM tool according to your use case. Not familiar with morphia. I guess hibernate is for RDBMS only. Hibernate OGM is for NoSQL databases.
For example, You can use Kundera if you want to query in JPA way like in RDBMS databases. It's an open-source object mapper for NoSQL databases supporting MongoDB, Cassandra, HBase, ONS, etc. It takes query in JPA format like
select p from Person p where p.salary > 20000
I think native is better, It seems ORM with Mongodb contains restrictions, (e.g, using eclipse-link you could not directly persist Map)
I wanted to ask you, if you have any experience that Hibernate OGM works as much fine with mongodb, that it could be used in an enterprise solution without any worries. With other words - does this combination work as fine as for example Hibernate ORM with MySQL and is is also that easy to set up? Is it worth to use it - meant the level of afford needed to set it up compared to the level of improvement of the work with the database? Would you prefer another OGM framework or even don't use any? I read about it some time ago, but it was in the early stages of this project and didn't work too well yet. Thanks for advices and experiences.
(Disclaimer: I'm one of the Hibernate OGM authors)
With other words - does this combination work as fine as for example Hibernate ORM with MySQL?
The 4.1 release is the first final we consider to be ready to use in production. The general user experience should be not much different from using the classic Hibernate ORM (which still is what you use under the hood when using Hibernate OGM). Also the MongoDB dialect probably is the one we put most effort in, so it is in good shape.
But as Hibernate OGM is a fairly young project, of course there may be bugs and glitches which need to be ironed out. Feature-wise, there are some things not supported yet (e.g. secondary tables, criteria API, more complex JPA queries), but you either shouldn't really need those in most kinds of applications or there are work-arounds (e.g. native queries).
and is is also that easy to set up?
Yes, absolutely. The set-up is not different from using Hibernate ORM / JPA with an RDBMS. You only use another JPA provider class (HibernateOgmPersistence) and need to set some OGM-specific options (which NoSQL store to use, host name etc.). Check out this blog post which walks you through the set-up. For store-specific settings (e.g. how to store associations in document stores) there is an easy-to-use option system based on annotations and/or a fluent API.
[Is it worth the effort] to set it up compared to the level of improvement of the work with the database?
I don't think there is a general answer to that. In many cases object mappers like Hibernate ORM/OGM are great, in others cases working with plain SQL or NoSQL APIs might be a better option. It depends on your use case and its specific requirements. In general, OxMs work well if there is a defined domain model which you want to persist, navigate its associations etc.
Would you prefer another OGM framework
I'm obviously biased, but let me say that using Hibernate OGM allows you to
benefit from the eco-system existing around JPA/Hibernate, be it integration with other libraries such as Hibernate Validator or Hibernate Search (or your in-house developed Hibernate-based API) or tooling such as modelling tools which emit JPA entities.
work with different NoSQL backends using the same API. So if chances are you need to integrate another NoSQL store (e.g. Neo4j to run graph queries) or an RDMBS, then Hibernate OGM will allow you to do so easily.
I read about it some time ago, but it was in the early stages of this project
Much work has been put into Hibernate OGM over the last year, so my recommendation definitely is to try it out and see in a prototype or spike how it works for your requirements.
If you have any feature requests or questions, please let us know and we'll see what we can do for you.
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!
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
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.
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:
Create an interface for each DAO
Create a higher level DAO implementation that simply calls my actual database specific implementation
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.
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.
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
JPA is all about data persistence; is data persistence only limited to RDBMS ? if not what are all the different persistence mechanisms (like Excel,File System,XML, NON RDMS etc ..) we can achieve with JPA specifications ?
JPA is designed for RDBMS, and looking at the API and metadata you can see that this is the case. It is possible to apply JPA to other datastores, but approximations have to be made for some concepts, particularly when querying. On the other hand the JDO API was designed for all datastores, and such approximations don't have to be made.
DataNucleus was the first implementation to provide JPA across a range of other datastores (Excel, ODBMS, ODF, LDAP, BigTable, HBase, MongoDB, etc), and has provided these for the last 2+ years. It also provides JDO access for the same datastores.
JPA is all about data persistence; is data persistence only limited to RDBMS ?
Yes.
JPA is a framework that provides an object / relational mapping. Relational is the "R" in RDBMS.
A project (Hibernate OGM) started recently to allow Hibernate to interface with NoSQL-type databases. The goal of the project is "to provide a common interface for NoSQL datastores using JPA constructs". (That is not the same as implementing JPA for NoSQL.) The article linked below describes the project as "nascent"; i.e. only recently started, don't hold your breath waiting.
References:
Java Persistence API - Wikipedia.
Hibernate Object Mapping for NoSQL Data Stores
JPA only defines standard mappings for relational data. But many JPA providers support non-relational data as well. Normally it is the runtime side of the API that is supported, mapping is normally done through non-standard meta-data.
Also there are many JDBC providers that support the JDBC API and SQL to non-relational data and data sources, which will work with any JPA provider. This is typically the best solution for accessing non-relational data.
There is no standard to mapping to non-relational data, as non-relational data encompasses a broad range of data formats, and are by definition non-standard. The Java Connector Architecture (JCA) standard is Java's standard for accessing non-relational data. However most non-relational adapters provide JDBC drivers instead of JCA drivers as JDBC usage is more widespread.
See,
http://en.wikibooks.org/wiki/Java_Persistence/Databases#EIS.2C_and_Non-relational_Data_Sources
EclipseLink has support for several persistence services including:
JPA
EIS (Enterprise Information Systems) non-relational data sources through JCA connectors
JAXB (mapping XML data)
DBWS (database web-services)
SDO (Service Data Objects)
The Java Persistence API deals with the way relational data is mapped
to Java objects ("persistent entities"), the way that these objects
are stored in a relational database so that they can be accessed at a
later time, and the continued existence of an entity's state even
after the application that uses it ends. In addition to simplifying
the entity persistence model, the Java Persistence API standardizes
object-relational mapping.
The qoutes are taken fro here:
http://www.oracle.com/technetwork/articles/javaee/jpa-137156.html
Shortly, yes. The JPA is about mapping of java objects to relational DB.
Is there a way to "abuse" the API and create implementation that maps objects to other targets like NOSQL? I believe it is possible but not very simple. How for example will you implement support of relational annotations like #OneToMany?