I'm writing an application that uses JPA for persistence. Currently I'm testing with Hibernate and a MySQL database. The server it's going to be deployed on already has ZODB running though. To avoid having to install MySQL especially for this app, it would be nice to use ZODB as the backend for JPA. Is this possible, with or without Hibernate?
Do you mean ZODB as in Zope Object Database? If so the answer is no. JPA is all about ORM (Object Relational Mapping), meaning your are working with relational databases. ZODB is a object database which is completely different thing. Why would you use JPA if you are going to use a object database?
No, the ZODB is a python-specific object database. It uses Python-specific tricks to load and store object state, something the JPA cannot provide (it is designed to map objects to relational databases).
No current implementation for persisting to ZOPE DB but you could add support for persisting it using JPA via DataNucleus by adding support for that DB. Sounds complicated but the basics is using doable in a couple of days ... as per
http://www.datanucleus.org/servlet/wiki/display/ENG/HOWTO+Support+a+new+datastore
DataNucleus already supports other object datastores via JPA (db4o, NeoDatis) hence why it ought to be doable
Related
I am writing a java application in which I am using Spring Boot and JPA in order to map classes to my database tables.
However, due to a somewhat complex database structure I also have the need of creating custom queries that are not mapped to any specific POJOs / Entities.
Therefore I am using PreparedStatement together with a DataSource with #Autowired annotation.
It hit me that using both of these DB Access methods might not be suitable to use together?
So far everything has worked out in my dev environment, but are there any pitfalls that I should look out for when using both of these together or is there a preferred way of doing custom queries when using JPA?
It should be noted that my database calls are fairly short and happen in a stateless manner, so there should hopefully not be any problems with interfering sessions (?)
JPA EntityManager will not know anything about your changes made with PreparedStatement. This will cause issues with JPA built-in caching, maybe with versioning and also with transaction support.
Though you may need to check this question: Is it OK to use both JPA (for normal CRUDs) and JDBC (for batch update & call stored proc) in the same project
Invan's answer makes a clear point.
On the other hand your fine when:
you need complex queries to SHOW data (read only).
you infrequently need to do some batch updates and do a clear cache entityManager.getEntityManagerFactory().getCache().evictAll()
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/
When developing for Microsoft Visual Studio and MS SQL Server, I would create stored procedures in MS SQL Server and a dataset in VS. The dataset is created with a wizard that effectively creates classes that my C# code can use to execute stored procedures and read data from the database. What is nice about this is that the classes abstract the interface with the database and provide an object oriented way of dealing with the database. The creation of classes from datasets guarantees strongly typed fields that are bound to actual database columns, which is really good. The real beauty with datasets is that if you change the database and refresh your dataset, it automatically rebuilds the classes. This prevents you from having a wrong data type in a class if you were to manually create those classes.
Is there something equivalent in Java / Eclispe development when working with a mySQL database? JDBC isn't an object oriented approach, so I'm wondering what alternative there is.
The most common way to communicate with a database in Java is probably to use an ORM framework such as Hibernate, possibly together with JPA. Hibernate abstracts database tables to Java classes, and uses JDBC under the hood.
Is there something equivalent in Java / Eclispe development when working with a mySQL database? JDBC isn't an object oriented approach, so I'm wondering what alternative there is.
Hibernate has a reverse engineering feature (Hibernate Tools). It allows you to automatically create Java classes from your database. Alternatively, you can let Hibernate create the database tables for you, which is specified by this parameter hibernate.hbm2ddl.auto=update.
This would probably be a good starting point.
I'm working on a Java webapplication and want to access the database (PostgreSQL) via an database API for security reasons. The API of the database is built by database functions.
How can I call the API functions with an EntityManager? I figured out a way with native queries, but I think then there is not much left of ORM. Is there a way for example to lead the entityManager.persist() method to one of the database functions?
This is not a good idea. The entire point of JPA is to standardize the way the database is accessed and mapped to the Object layer. If you want to use native DB functions then you should use JDBC, possibly via SpringJDBCTemplate or some other tool that eases some of the pain. If you really feel like punishing yourself though, you could always create your own implementation of EntityManager and use that in your classes.
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