I'm wondering if it is possible to specify SimpleJPA as the persistence provider used by Spring-Data-JPA. I'm not a JPA expert so I hope this question isn't silly. Is it as easy as just specifying SimpleJPA's entity manager factory in the persistence.xml? I have yet to find anywhere online where someone has used Spring-Data-JPA to connect to Amazon's SimpleDB, I would love it if someone could point me in the right direction.
I just found this project and got it working for our Spring Data + SimpleDB needs:
https://github.com/3pillarlabs/spring-data-simpledb
The documentation is pretty good and getting things up and running was pretty straight-forward. I was accessing SimpleDB via Spring Data with about 10 minutes of work.
Generally setting up your persistence provider is just a matter of setting up the EntityManagerFactory through your Spring context (in case you use the Spring container). Thus have a look at how to configure EntityManagerFactory instances in Spring.
There might be the need to implement a custom JpaVendorAdapter to let Spring use the SimpleDB JPA implementation correctly. For some advanced functionality (e.g. using pagination with manually defined queries) we'd have to tweak the Spring Data JPA codebase a bit. If you'd like to see that supported feel free to open a ticket in our JIRA.
Related
I have an application which is using Spring data JPA and hibernate envers for db auditing.
Since R2DBC doesn't support auditing yet, is it possible to use combination of both in a single application?
If yes, Plan is to use Spring Data JPA for insert, update and delete operations, so that all DB auditing will be handled by hibernate envers. And use R2DBC for reactive non-blocking API's to read data.
If no, Is there any suggestions on how to achieve both reactive API's and auditing?
Spring provided simple Auditing via #EnableR2dbcAuditing, check my example.
Mix JPA in a reactive application is also possible, I have an example to demo run JPA in a reactive application, but not added r2dbc in it.
For your plan, a better solution is applying the cqrs pattern on the database topology, use database cluster for your application.
JPA for applying changes, use the main/master database to accept the modification, and sync changes to the secondary/slave database.
r2dbc for queries as you expected, use the secondary/slave database to query.
use a gateway at the front for the query and command service.
Update: I have created a sample to demo JPA and R2dbc coexistence in a single webflux application. But I do not suggest using it in real-world applications. Consider the 3rd solution above if you really need it.
Yes it is possible however you will probably face two issues, one is that multiple repos modules handling needs to be explicited (e.g specify the paths of the respective modules).
Secondly, the JDBC/JPA Spring Boot autoconfiguration will be disabled and you need to import it back.
Those issues have been reported in Reactive and Non Reactive repository in a Spring Boot application with H2 database
And a solution to them and the thought process can be found in this issue:
https://github.com/spring-projects/spring-boot/issues/28025
I am implementing a new spring-boot application with mongoDB, earlier worked with djangoAdmin. Looking for a similar solution which can easily generate management UI for all classes decorated with #document.
Have you seen JHipster?
It uses an Angular frontend with a Spring Boot backend but comes with a ton of admin functionality right out of the box. This includes the turn-key CRUD operations like you mentioned.
There is http://lightadmin.org project. But it currently supports only Spring Data JPA.
I would like to add some persistence to save some application data and I feel like I have searched the web for days without any success.
I have found some older links and the eclipse Gemini project. However, I suppose I am too new to understand the implementation or it is just a little dated. Probably, more of my lack of knowledge.
Anyway, is anyone willing to point me to a working example and/or provide me with some assistance offline?
If you want to use H2 with plain JDBC, you won't need the Gemini project. In this case you can wrap the H2.jar with the corresponding JDBC driver in a single bundle (plugin) and implement your db access there.
The Gemini project is for using persistence via JPA, which works with any JDBC capable database.
In either case, be aware that in an OSGi environment like Eclipse RCP, there is one classloader per bundle. This leads to lots of complications. We are using Hibernate as JPA engine within our E4 application and we cannot split the JPA configuration, the JPA engine and the entity beans :-(
We tried using EclipseLink as JPA engine but this doesn't work on all our entities :-(
I found this blog article by Raja Kannappan which briefly explains class loading in OSGi.
You can read more about JPA in The Java EE Tutorials (although JPA is part of Java SE, too).
Hope this helps.
want to develop my project on Google App Engine .I want to use google big table as database. For the database I have two options JPA and JDO. Will you guys please suggest me on it? Both are new for me and I need to learn them. So I will be focused on one after your replies.
Since you're using Data Nucleus, see their FAQ on JDO vs JPA. http://www.datanucleus.org/products/accessplatform_3_0/jdo_jpa_faq.html
DataNucleus AccessPlatform supports both JDO and JPA specifications of Java persistence. As such it has no "vested interest" in either technology, believing that it is for users to choose which they like best. There has been much FUD on the web about JDO and JPA, largely perpetrated by RDBMS vendors. This FAQ corrects many of these points
A key difference is that JDO support a rich domain model (logic together with data), in fact all persistent classes can have a reference to the current PersistenceManager, issue queries, and, I guess, it's possible not to have fields persistent by default.
JPA does not support such software design. In fact each Entity doesn't have a reference to the PersistenceManager, to have it you have to resort to ThreadLocal variables, which is not a very elegant and robust solution.
Since GAE BigTable is not an RDBMS, JDO is a better choice. There are some detailed comparision articles in Aphache JDO, it is helpful for me.
JPA persists java objects to relational data via ORM, while JDO is more general specification for java object persistence. So using JDO will give you more freedom in storage implementation options for your objects.
JPA is the leading java standard for persistence. So I'll say use JPA if you are using RDBMS and require ORM.
Hibernate is generally used as JPA implementation. If you need some extra features you can use hibernate specific annotations.
This question already looks to be discussed here JDO vs JPA for Java on Google App Engine
We use EJB2.x entity beans with BMP (bean managed persistence). It appears BMP is not supported in EJB3. We had wanted to stay current and upgrade to EJB3. Does anyone know if there are in fact any BMP options available in 3.0?
From what I can tell, using 3.0, all entity beans have to use JPA and by definition ORM. There are some options to use native SQL but that is still just a way to use JPA to implement ORM.
I wasn't sure if there is another EJB3 approach to achieve the same functionality as with EJB2.x BMP entity beans. We currently use the standard ejbStore method to update the DB through native SQL and the ejbLoad method to lookup all beans and to refresh the bean in the event of a transaction rollback. I thought you might be able to do this with EJB3 session beans but I wasn't sure.
Perhaps instead of migrating to EJB3 beans we should migrate to Spring.
If you really want to code SQL by hand, go for POJOs and raw JDBC DAOs. But this is also maybe an opportunity to rethink the way you're doing things and embrace ORM/JPA.
In the past, I have mixed Hibernate + EJB2 (CMP + BMP) sharing transactional contexts with no issues, using JTA.
This problem is quite similar...
Take a look at https://cwiki.apache.org/GMOxDOC22/developing-bean-managed-persistence-with-jpa.html. You can implement your own EntityManager.
With luck, you may be even able to share transactional contexts.