continuum-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Edward Gruber <cgru...@israfil.net>
Subject Re: Some continuum-jpa branch updates
Date Fri, 18 Jan 2008 20:57:05 GMT
You can get some benefit from named queries in terms of query pre- 
compilation and caching on the underlying database.  However, most  
database flavors and hibernate providers turn criteria queries into  
named queries (parameterized SQL) which is then cached, so, on the  
surface I suspect the performance characteristics will be similar.

Christian.

On 18-Jan-08, at 14:35 , Rahul Thakur wrote:

>
> Thanks Emmanuel! Responses inlined...
>
> Emmanuel Venisse wrote:
>> Hi Rahul,
>>
>> After few days to look at JPA, I'm sure now it would be good to use  
>> it
>> instead of the actual JDO/JPOX (I know JPOX 1.2 support JPA).
>> The code is very easy to write and to read with JPA.
>>
>> About your continuum-jpa branch, I have few remarks:
>> - I don't think it's good to use directly some OpenJPA APIs. If  
>> possible,
>> I'd prefer to use only standard JPA APIs so we'll can choose later  
>> the
>> implementation we want to use (OpenJPA, TopLink, JPOX...)
>>
> Agree. The only place where OpenJPA APIs are being used directly  
> currently are the unit tests.
>> - why do you use some Spring code?
>>
> Experimental. Spring has a good transaction management framework out  
> of the box.
>> - we don't need to store the model encoding  
>> (CommonUpdatableModelEntity
>> class)
>>
> Sure. Easily fix'able. :-)
>> - can you explain dateCreated/dateUpdated fields? How are they  
>> managed?
>>
> These are for audit puposes, and can be used as range search query  
> criteria for fetching entities. These were an extension I thought  
> will be good. 'dateCreated' gets set when an entity is first  
> inserted into the underlying store, subsequent updates update the  
> 'dateUpdated'.
>> - all the model is fectched eagerly and it isn't acceptable for  
>> performance
>>
> Yes, the model does needs review and tweaks to annotations where we  
> know we don't need to fetch 'eagerly'.
>> - I'm not sure your Query "pattern" is good. I'd prefer to use  
>> named queries
>> but maybe you have a reason
>>
> I think using a Query like we have on the JPA branch nicely provides  
> for a flexible construction of queries (i.e, only the criteria  
> passed in contributes to the query). I am not sure if such is  
> available with named queries; but I am interested to know why named  
> queries might be better.
>
> Cheers,
> Rahul
>
>> That's all for the moment.
>>
>> Emmanuel
>>
>> On Jan 16, 2008 11:30 PM, Rahul Thakur  
>> <rahul.thakur.xdev@gmail.com> wrote:
>>
>>
>>> Just wondering if anyone else got to the changes?
>>>
>>>
>>> Emmanuel Venisse wrote:
>>>
>>>> I don't have the time to look at it these days but I'll do it asap
>>>> (maybe in few weeks :( )
>>>>
>>>> Emmanuel
>>>>
>>>> Rahul Thakur a écrit :
>>>>
>>>>> Hi All,
>>>>>
>>>>> Scribbling some quick notes on some of the toying around I have  
>>>>> been
>>>>> doing with OpenJPA, Generics etc on the continuum-jpa branch[1]:
>>>>>
>>>>> 1) Use JPA for persistence
>>>>> Motivation behind this has been to investigate how this compares  
>>>>> to
>>>>> JPOX/JDO for managing the model - both in terms on performance and
>>>>> ease of use (Store APIs). Continuum model classes are annotated  
>>>>> with
>>>>> JPA annotations on the branch. However, this needs a review as  
>>>>> there
>>>>> are some elements (for example 'configuration' typed as Map)  
>>>>> that I am
>>>>> not sure yet how to persist yet. The provider used is OpenJPA [2].
>>>>>
>>>>> 2) Refactorings to Store interface
>>>>> Main motivation has been to keep the core Store interface lean and
>>>>> mean (read extensible). The Store interface[3] now has 4 methods:
>>>>> lookup()
>>>>> save()
>>>>> delete()
>>>>> query()
>>>>>
>>>>> The lookup(), save() and delete() act on single model Entity,  
>>>>> while
>>>>> query() will filter and obtain matching Entities from the  
>>>>> underlying
>>>>> database based on the Query specified. Query implementations  
>>>>> control
>>>>> how a resulting JPQL gets constructed and which matching  
>>>>> entities get
>>>>> pulled, and can be easily extended.
>>>>>
>>>>> To preserve compatibility with the existing Store interface, we  
>>>>> can
>>>>> mimick the existing ContinuumStore interface operations by  
>>>>> having a
>>>>> facade that can prepare requisite queries and delegate to a Store
>>>>> instance.
>>>>>
>>>>> 3) Misc.
>>>>> There are a few I am investigating:
>>>>> 1) Spring/Guice under the hood.
>>>>> 2) JUnit 4.4 (and Hamcrest library)
>>>>> , but these are still in early stages.
>>>>>
>>>>> I am keen to get a feedback on what others think.
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Rahul
>>>>>
>>>>>
>>>>> [1] -
>>>>> http://svn.apache.org/repos/asf/maven/continuum/branches/continuum-jpa/
>>>>>
>>>>> [2] - http://openjpa.apache.org/
>>>>>
>>>>> [3] -
>>>>>
>>>>>
>>> http://svn.apache.org/repos/asf/maven/continuum/branches/continuum-jpa/continuum-model-jpa/src/main/java/org/apache/maven/continuum/store/api/Store.java
>>>
>>>>>
>>>>>
>>
>>
>


Mime
View raw message