On Jan 22, 2008 3:06 AM, Rahul Thakur [EMAIL PROTECTED] 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[EMAIL PROTECTED]
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
[EMAIL PROTECTED] wrote:
Just wondering
