I would like to be able to write linq-style specific queries in java using jinq (http://www.jinq.org/index.html) and the java 8 streams. However, in the set-up section it says you need to use the JPA entityManagerFactory (http://www.jinq.org/docs/queries.html#N65755). In my project I am using hibernate and the sessionFactory. Does that mean that I cannot use jinq at all or there's some workaround?
Simple viewing of the javadoc for "JINQ" shows very clearly that they take in a JPA "EMF", so you have to use JPA to use it.
I see no downside of using JPA. You can easily enough dip in to vendor specifics when you really need to and still use JPA for the majority
Related
I want to remove direct Hibernate references from my Java EE 7 server application so that I will not have a compile-time dependency on hibernate-core in the future. As a replacement, I want to use the plain JPA API.
So far, I figured out that org.hibernate.annotations.Cascade and org.hibernate.annotations.CascadeType can be mostly transferred to the cascade-parameter of JPA's #ManyToOne or #OneToMany.
Also, org.hibernate.annotations.Type seems to be replaceable by a suitable JPA #Converter.
However, there are more usages of Hibernate in my code where I am struggling more:
org.hibernate.annotations.Immutable
org.hibernate.annotations.OptimisticLock
org.hibernate.annotations.DiscriminatorOptions
org.hibernate.annotations.Fetch
org.hibernate.EmptyInterceptor
Could you give me any hints if and how those can be migrated to JPA? Alternatively, links to a Hibernate → JPA migration guide/tutorial would be very appreciated.
You can't replace these unless you want to rewrite your application. You shouldn't try to avoid these annotations IMO as that would just leave you with a bad performing application that is probably still not portable. Hibernate is the de-facto JPA implementation, so I doubt you want to move away from it.
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()
I know this is a newb question, but that's what I am so here goes.
I am writing an application in java that has a lot of H2 database queries so far I have written methods that pull the data I need from the database with queries, because this is the only way I know how.
My question is, is there an easier way to go about getting data from my database that would be more efficient and make things less work. In my research Spring does something like this, but if it does I have been unable to find good information on how to implement it.
Thanks,
I would say there is even better approach called Java Persistence API. It will make your code ORM agnostic and provide some flexibility.
JPA 2.0 is quite rich and will satisfy all your needs. So I do not think you should use Hibernate directly, instead you should try to use JPA where you can. Please note, Hibernate is JPA 2.0 provider.
Please see the following example Creating Good DAOs with Hibernate 3.5 and JPA 2.0 Annotations
There are many options. As ShyJ wrote, Spring Data JPA is one. Many people use Hibernate. There are other libraries you could use, for example SimpleORM.
But I wonder if "which one is better" is the right type of question for StackOverflow. There are many ways to do it "right", and many things to consider.
I am also using H2 rather heavily in a large environment. My advice is to use JPA and particularly Hibernate as it is one of the most popular implementation.
What you want to avoid is writing native sql as if you are going to change a database (if you are) you will run into numerous problems with native sql. JPA solves it by defining JPQL which is like SQL, but will work on any database.
Another great benefit from hibernate is the possibility of using L2 cache which can speed up your application drasticaly.
The last benefit is perhaps most relevant to you- it may take you slightly longer to set up, but once its there, it is much easier to work with the database from pure java.
In the screen where you can add the Hibernate library to a project, there are two options, Hibernate and Hibernate JPA.
What is the difference between the 2? Googling did not provide an explanation.
I found this to provide a good explanation.
http://elope.wordpress.com/2007/09/06/difference-between-jpa-and-hibernate/
From the above blog:
So if i need to put in Concise words:
a) JPA is Persistence Api which your code should use.
b) JPA Api will pass on the call to actual peristence provider (ex:Hibernate/TopLink) to do the actual work.
c) If you are looking from Performance prespective ,it will be dependent on actual peristence provider (Hibernate/TopLink) and not on JPA as its just a wrapper layer.
d) If you are looking from code dependency prespective ,JPA makes more sense as your code is dependent on standard Java Api.
e) If you have used Hibernate then you will find that certain features are missing in JPA like criteria queries etc.This does not mean that you can’t write criteria query in your application, you need to get Session object from JPA Entity manager and now you are as good as in hibernate project.
But now your code is dependent on Specific impl (Hibernate),going forward you can see more things getting added in JPA (2.0)
f) Should you use JPA: My take is you should ,API is clean and although not everthing you need is their but is a good step forward.
I don't know what "screen" you mean, but in general you can use Hibernate directly (Hibernate API) or as a JPA provider. As JPA is a standard API one can code against this API and switch between implementations (Hibernate, EclipseLink, OpenJPA, ...). When using Hibernate API you are tied to this but you can utilize features that are not standardized by JPA.
With Spring 3.0 is it recommended to use hibernate or JPA.What are the advantages and disadvantages of both of them when used with Spring 3.0 ?
Note : We are also suppose to use it with Spring Data Access.
I would say, JPA implementation provided by Hibernate. Why? Because
It would be easier to switch to some other JPA implementation later, if you you ever need to
Hibernate is the one of the major and most popular ORM around
Lot of books available
Extensive documentation, awesome reference material
Easy to get support on SO, and elsewhere
Actually, I don't mind to use Hibernate exclusive features too. I don't see any problem in sticking with Hibernate, just because its not an standard. And by the way, what makes you think Spring is standard. Its not, and you are fine with it, because it works. Similar thing can be said for Hibernate. Hibernate sometimes get hairy, if you don't know well what you are doing.
My preference is JPA with EclipseLink. Reasons:
JPA is standard, Hibernate is not
Use EclipseLink because JPA with Hibernate has some weird implementation. EclipseLink is also the reference implementation for JPA 2.0
Bozho: there are some that I found, unfortunately it is not so obvious because it only happens in some extreme cases. Some that I can think:
Convert JQL to CriteriaBuilder
ElementCollection works fine with JoinTable, which is wrong! ElementCollection should be accompanied by CollectionTable.
To be precise, you should use the Java Persistence API, and then you can use Hibernate as an implementation.
JPA without an implementation isn't worth anything.
JPA is a standard, so if you only use it's API, you can substitute Hibernate with some other JPA implementation. If you use some of Hibernate's specific API because you need functionality not provided with plain JPA, you'll have a vendor lock-in scenario, so you'll have to be careful about this.
It depends on our application.
If you are not sure that you will never need to change your persistence provider, it is strongly recommended to use JPA (2.0)
If you are sure that you never will change your persistence provider, than I recommend using JPA (2.0) too. But (only) in this case you have the possibility to use a proprietary feature of you choosen JPA-Provider, if you have a problem not solved by standard JPA. -- But use it wise, if you choose this way once, it is hard to go back!
Of course JPA is just an API - so you need an implementation of it. -- I used Hibernate as JPA provider, but mainly because I am allways in the second scenario (will never change it), and I needed additional features like Hibernate-Search and Envers.