Re: Some continuum-jpa branch updates

[Rahul Thakur <ra...@gmail.com>]

I would have liked this thread to merge with Continuum 2.0 discussion 
thread, but anyway...

Its seems TopLink can do Criteria Queries (using Expressions and 
ExpressionBuilders, correct me if I am wrong). It seems quite a few JPA 
implementations provide some sort of Criteria Query API extension. And 
from what I gather online, its quite likely that JPA 2.0 would 
standardize a Criteria API.

So, no more performance overhead of String concatenations ;-)

Rahul

Christian Edward Gruber wrote:
> 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 <cg...@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
>>>>> <ra...@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 
>>>
>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>
>

Re: Some continuum-jpa branch updates

[Damien Lecan <ml...@dlecan.com>]

> Its seems TopLink can do Criteria Queries (using Expressions and
> ExpressionBuilders, correct me if I am wrong). It seems quite a few JPA
> implementations provide some sort of Criteria Query API extension.

Hibernate does that too !

Damien

Re: Some continuum-jpa branch updates

[Christian Edward Gruber <cg...@israfil.net>]

Nice!

On 6-Feb-08, at 00:31 , Rahul Thakur wrote:

> I would have liked this thread to merge with Continuum 2.0  
> discussion thread, but anyway...
>
> Its seems TopLink can do Criteria Queries (using Expressions and  
> ExpressionBuilders, correct me if I am wrong). It seems quite a few  
> JPA implementations provide some sort of Criteria Query API  
> extension. And from what I gather online, its quite likely that JPA  
> 2.0 would standardize a Criteria API.
>
> So, no more performance overhead of String concatenations ;-)
>
> Rahul
>