Hi Christian I understand your point of view, but I not agree. JPA define API, so it is an abstraction. My application MUST be independent from the implementation. Think about this. I have a software based on postgreSQL that use OpenJPA. For some reason a new customer buy my software with the constraint that it has to use MySQL. In this case, using your approach I have to use OpenJPA with MySQL, but this combination is not performing. From my experience, the best JPA implementation for mysql is Eclipselink. Using my approach I have the chance to deploy my software on mysql using eclipse without change the code!!! Not only. Using my approach, without change the code, I can do several test in the real environment to select the best combination between DBMS and JPA implementation from performance point of view. However, I have to say that write jpa query (using criteria builder) independent from the JPA implementation and from DBMS is a bit complex.
I think that my use case is not so common, but I have this need and using Spring ORM can satisfy it. This is because I open the ARIES-1295 issue and open a pull request to fix it. Regards Giuseppe 2015-04-03 1:03 GMT+02:00 Christian Schneider <ch...@die-schneider.net>: > Why should that make sense? Changing the persistence framework is much > more than the schema generation and other properties. > They all have slight differences when you create real applications. > Exchanging the JPA impl on the fly is not feasible and I can not imagine a > use case where it is necessary. > > Also the ddl generation is normally not working once you create bigger > applications. The reason is that you want to manage the schema and provide > a clearly defined migration of the schema when you deploy. I have seen > people use liquibase for that case with good success. For my examples I of > course use the schema generation but that is not how people do it in bigger > projects. > > So my assumption is that you probably will not really need properties > where you inject the EntityManager. What might make sense though is to for > example provide a way to set properties on the persistence unit level using > config admin. That should be easy to do and would even help with your use > case .. even if I doubt it is realistic. > > Christian > > > Am 02.04.2015 um 23:13 schrieb Giuseppe Gerla: > >> Hi Christian >> thanks for explanation. I hope to make some tests during next week-end. >> >> About properties, I'd like to have a persistence.xml without reference to >> JPA implementation, only classes list. Implementation should be changed >> without re-compile the bundle. >> So for example if I have a property to define the schema creation in the >> persistence.xml like >> >> <property name="hibernate.hbm2ddl.auto" value="create-drop"/> >> >> and replace hibernate with eclipselink, I have to replace the >> persistence.xml with >> >> <property name="eclipselink.ddl-generation" >> value="drop-and-create-tables"/> >> >> and I have to deploy a new version of my bundle. >> Using blueprint and hot-configuration of Karaf it could be possible to >> change the property using a configuration file. >> >> Regards >> Giuseppe >> >> >> 2015-04-02 21:26 GMT+02:00 Christian Schneider <ch...@die-schneider.net>: >> >> Hi Giuseppe, >>> >>> the main thing missing is the more advanced transaction handling. >>> Currently for blueprint the transaction starts at the outermost place >>> where an EntityManager or EmSupplier is injected. >>> So it is as if you would use a @Transactional with Required type on each >>> such class. >>> >>> Apart from that you should already be able to write jpa applications with >>> the current code. >>> >>> Currently only the persistence.xml is regarded for creating the >>> EntityManagerFactory. While you can add properties to the >>> @PersistenceContext annotation they are not used. >>> Honestly I do not understand anyway how you would handle such properties. >>> You could have different properties at every @PersistenceContext for the >>> same unit name. As we are only creating the EntityManager at the >>> outermost >>> call the other properties can not be applied. Can you explain what use >>> case >>> you have in mind for the properties? >>> >>> Christian >>> >>> >>> Am 02.04.2015 um 18:48 schrieb Giuseppe Gerla: >>> >>> Hi Christian >>>> I would be very interested to try the new prototype, but I have few >>>> time. >>>> So before I start, I would like to ask you: >>>> 1. you say that the current code is not yet complete. What is missing? >>>> What >>>> functionalities I will not test? >>>> 2. Is it possible or it will be possible to set some properties to the >>>> EMF? >>>> (something like jpa:map functionality. See >>>> https://issues.apache.org/jira/browse/ARIES-1295 >>>> >>>> Thanks for your work >>>> Regards >>>> Giuseppe >>>> >>>> >>>> 2015-04-02 15:41 GMT+02:00 Christian Schneider <ch...@die-schneider.net >>>> >: >>>> >>>> I am experimenting for some time with a new way to implement jpa >>>> support. >>>> >>>>> You can find the design on this website: >>>>> http://liquid-reality.de/display/liquid/New+design+for+aries+jpa >>>>> >>>>> The prototype code is at: >>>>> https://github.com/cschneider/jpa-experiments >>>>> >>>>> The goals for the new design are: >>>>> - Simpler and more robust implementation using OSGi service dynamics. >>>>> Tracking all dependencies and publishing / unpublishing >>>>> EntityManagerFactory when any go away >>>>> - Move some functionality to other projects like wrapping XA >>>>> DataSources >>>>> to pax-jdbc. >>>>> - Support for other frameworks like declarative services using >>>>> JPATemplate >>>>> and closures >>>>> >>>>> The current code is not yet complete but already works for blueprint >>>>> and >>>>> DS. >>>>> >>>>> I would be happy about any feedback. >>>>> >>>>> Especially I would be interested if with the new approach Quiesce is >>>>> still >>>>> necessary. The code already makes sure that the EntityManagerFactory is >>>>> nicely cleaned up. EntityManagers are only held for the duration of a >>>>> request. So if blueprint Quiesce shuts down the requests then I think >>>>> the >>>>> jpa impls should not need to do additional work here. I tested to >>>>> update >>>>> all modules at runtime and all seems to work nicely. With the current >>>>> aries >>>>> jpa I can not update the persistence unit bundles. See >>>>> https://issues.apache.org/jira/browse/ARIES-1270 >>>>> >>>>> Christian >>>>> >>>>> -- >>>>> Christian Schneider >>>>> http://www.liquid-reality.de >>>>> >>>>> Open Source Architect >>>>> http://www.talend.com >>>>> >>>>> >>>>> >>>>> >
