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


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.


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.

On Jan 18, 2008 9:57 PM, Christian Edward Gruber <[EMAIL PROTECTED]>

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.


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
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
I'd prefer to use only standard JPA APIs so we'll can choose later
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

Sure. Easily fix'able. :-)
- can you explain dateCreated/dateUpdated fields? How are they

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
- all the model is fectched eagerly and it isn't acceptable for

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.


That's all for the moment.


On Jan 16, 2008 11:30 PM, Rahul Thakur

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 :( )


Rahul Thakur a écrit :

Hi All,

Scribbling some quick notes on some of the toying around I have
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
JPOX/JDO for managing the model - both in terms on performance and
ease of use (Store APIs). Continuum model classes are annotated
JPA annotations on the branch. However, this needs a review as
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:

The lookup(), save() and delete() act on single model Entity,
query() will filter and obtain matching Entities from the
database based on the Query specified. Query implementations
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
mimick the existing ContinuumStore interface operations by
having a
facade that can prepare requisite queries and delegate to a Store

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.



[1] -


[2] - http://openjpa.apache.org/

[3] -


Reply via email to