aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Giuseppe Gerla <giuseppe.ge...@gmail.com>
Subject Re: Prototype for a new aries jpa impl
Date Fri, 03 Apr 2015 07:44:39 GMT
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 <chris@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 <chris@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 <chris@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
>>>>>
>>>>>
>>>>>
>>>>>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message