Some continuum-jpa branch updates

[rahul.thakur.xdev]

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

[Erik Bengtson-2]

FYI, jdo 2.1 supports JPA 1.0 annotations. That would be helpful to interchange jdo and jpa apis. However when that comes to non RDBMS datastores, such as db4o jpa annotations would not be a good match. Another advantage of JPA annotations is tooling, eg eclipse dali or NetBeans. My selection criteria would start with asking if remaining datastore agnostic is mandatory, then operational speaking which implementation provide the best tools to troubleshoot, diagnostic and manage the runtime app, finally dev tools.

Cheers
--   BlackBerry® from Mobistar    ---

-----Original Message-----
From: "Rahul Thakur" <rahul.thakur.xdev@...>

Date: Mon, 10 Dec 2007 12:04:51
To:continuum-dev@...
Cc:Rinku <rahul.thakur.xdev@...>
Subject: Some continuum-jpa branch updates


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

[Emmanuel Venisse]

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
>
>

[rahul.thakur.xdev]

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 
>>
>>
>>
>

[Emmanuel Venisse-2]

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...)
- why do you use some Spring code?
- we don't need to store the model encoding (CommonUpdatableModelEntity
class)
- can you explain dateCreated/dateUpdated fields? How are they managed?
- all the model is fectched eagerly and it isn't acceptable for performance
- I'm not sure your Query "pattern" is good. I'd prefer to use named queries
but maybe you have a reason

That's all for the moment.

Emmanuel

On Jan 16, 2008 11:30 PM, Rahul Thakur <rahul.thakur.xdev@...> 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
> >>
> >>
> >>
> >
>

[rahul.thakur.xdev]

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@...> 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
>>    
>>>>
>>>>        
>
>  

[Christian Edward Gruber]

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@...> 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
>>>
>>>>>
>>>>>
>>
>>
>

[Emmanuel Venisse-2]

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@...>
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@...> 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
> >>>
> >>>>>
> >>>>>
> >>
> >>
> >
>
>

[Emmanuel Venisse-2]

I think it would be good to introduce some partial object like
ProjectGroupWithoutProjects that we can use in JPQL request so we won't use
non detached fields and we'll know exactly what we use and where.

Emmanuel

On Jan 21, 2008 10:59 PM, Emmanuel Venisse <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@...>
> 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@... > 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
> > >>>
> > >>>>>
> > >>>>>
> > >>
> > >>
> > >
> >
> >
>

[Christian Edward Gruber]

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@...>
> 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@...> 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
>>>>>
>>>>>>>
>>>>>>>
>>>>
>>>>
>>>
>>
>>

[Rahul Thakur-4]

A Query object that wraps up criteria and is built programmatically
affords us the ability to keep Store APIs lean and stable. That is the
motivation behind building up queries programatically. IMHO, the current
ContinuumStore is a bunch of methods that don't even vary that much
underneath. I think the same can be easily achieved by using Query.

I am not sure if StringBuilder will be more performant than StringBuffer
when you are concatenating only a few Strings. I think what is more
important is a goal of a lean, test'able and clean API.

I can't really comment on named queries (probably need to toy around
with them a bit), and not sure how the implementation would end up
making use of named queries, but if anyone else has any opinions, I am
keen to understand.

Cheers,
Rahul

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@...>
> 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@...>  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
>>      
>>>>>>>                
>>>>          
>>      
>
>    

[rahul.thakur.xdev]

(Sorry if this is a duplicate post; for some reason this didn't make it
to the list earlier)

A Query object that wraps up criteria and is built programmatically
affords us the ability to keep Store APIs lean and stable. That is the
motivation behind building up queries programatically. IMHO, the current
ContinuumStore is a bunch of methods that don't even vary that much
underneath. I think the same can be easily achieved by using Query.

I am not sure if StringBuilder will be more performant than StringBuffer
when you are concatenating only a few Strings. I think what is more
important is a goal of a lean, test'able and clean API.

I can't really comment on named queries (probably need to toy around
with them a bit), and not sure how the implementation would end up
making use of named queries, but if anyone else has any opinions, I am
keen to understand.

Cheers,
Rahul

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@...>
> 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@...> 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
>>    
>>>>>>>              
>>>>        
>>    
>
>  

[Emmanuel Venisse-2]

On Jan 22, 2008 3:06 AM, Rahul Thakur <rahul.thakur.xdev3@...> wrote:

>
> A Query object that wraps up criteria and is built programmatically
> affords us the ability to keep Store APIs lean and stable. That is the
> motivation behind building up queries programatically. IMHO, the current
> ContinuumStore is a bunch of methods that don't even vary that much
> underneath. I think the same can be easily achieved by using Query.
>

With named queries, queries are cached in the persistence context so they
don't need to be parsed each time.
With named queries, an other good thing is that they can be overriden in the
xml file if needed for performance for a specific DB and we can add query
hints.
The last thing is that with named queries, we know exactly which requests we
execute so we can optimize the DB schema with some index, it isn't easy to
do with dynamic queries.

I don't say we won't use dynamic queries but only that it must be the
majority of our requests and it's a JPA best practices.


>
> I am not sure if StringBuilder will be more performant than StringBuffer
> when you are concatenating only a few Strings. I think what is more
> important is a goal of a lean, test'able and clean API.
>

It isn't important for a concatenation of few strings, but in your code, you
do it in the Query generator. The concatenation will executed a lot because
we execute lot of requests in all pages, so the benefit of StringBuilder is
very important.

>
> I can't really comment on named queries (probably need to toy around
> with them a bit), and not sure how the implementation would end up
> making use of named queries, but if anyone else has any opinions, I am
> keen to understand.
>
> Cheers,
> Rahul
>
> 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@...>
> > 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@...>  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
> >>
> >>>>>>>
> >>>>
> >>
> >
> >
>
>

[rahul.thakur.xdev]

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 <cgruber@...>
>> 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@...> 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 
>>>
>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>
>

[Christian Edward Gruber]

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
>

[Damien Lecan 2]

> 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