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 Mon, 21 Jan 2008 22:11:15 GMT
You can still use parameterized queries dynamically, you just use  
strings that contain "?" and they get turned into pre-compiled queries  
in the db.

However, named queries can be further optimized by Hibernate before it  
even gets to the db (pre-compiling at load, etc.)

Criteria queries are the other way to go.  They're programmatically  
constructed and they can get a lot of the jdbc benefits of named  
queries.

Christian.

On 21-Jan-08, at 16:59 , Emmanuel Venisse wrote:

> As Christian said, named queries are pre-compiled to SQL. With dynamic
> queries, perf can be not good because for each execution, the JPQL  
> request
> is recompile to SQL, so parsing, creation of the JPQL tree then SQL
> generation, and with your solution, you concatenate lot of String.  
> It isn't
> important for one request but with lot of request, you use more time  
> and
> cpu, for string concatenation, it is better to use StringBuilder  
> that is
> more performant than String addition or StringBuffer.
>
> An other argument for named queries is that with dynamic queries, if  
> they
> aren't written correctly (it isn't the case for your code ;) ), it  
> is easy
> to introduce some malicious SQL code with parameters
>
> my two cents.
> Emmanuel
>
> On Jan 18, 2008 9:57 PM, Christian Edward Gruber <cgruber@israfil.net>
> wrote:
>
>> 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