Mailing-List: contact continuum-dev-help@maven.apache.org; run by ezmlm
Precedence: bulk
Reply-To: continuum-dev@maven.apache.org
Received-SPF: pass (athena.apache.org: local policy)
Message-Id: <06AF7A80-6F9F-4B08-BB2F-251D4F2CD261@israfil.net>
From: Christian Edward Gruber <cgruber@israfil.net>
To: continuum-dev@maven.apache.org
In-Reply-To: <f345f3480801211359v5121284bu550027dff6809c1e@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes
Content-Transfer-Encoding: quoted-printable
Subject: Re: Some continuum-jpa branch updates
Mime-Version: 1.0 (Apple Message framework v915)
Date: Mon, 21 Jan 2008 17:11:15 -0500
References: <5d3354e30712091504n5e5bc3e5g27823312f3124f16@mail.gmail.com>
 <47603A17.3010002@venisse.net> <478E8589.7090801@gmail.com>
 <f345f3480801180618jf18d111w442607939ff27dd3@mail.gmail.com>
 <4790FF8C.7030702@gmail.com>
 <F075458D-63EC-4187-9F09-C417F3322F1D@israfil.net>
 <f345f3480801211359v5121284bu550027dff6809c1e@mail.gmail.com>

You can still use parameterized queries dynamically, you just use =20
strings that contain "?" and they get turned into pre-compiled queries =20=

in the db.

However, named queries can be further optimized by Hibernate before it =20=

even gets to the db (pre-compiling at load, etc.)

Criteria queries are the other way to go.  They're programmatically =20
constructed and they can get a lot of the jdbc benefits of named =20
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 =20
> request
> is recompile to SQL, so parsing, creation of the JPQL tree then SQL
> generation, and with your solution, you concatenate lot of String. =20
> It isn't
> important for one request but with lot of request, you use more time =20=

> and
> cpu, for string concatenation, it is better to use StringBuilder =20
> that is
> more performant than String addition or StringBuffer.
>
> An other argument for named queries is that with dynamic queries, if =20=

> they
> aren't written correctly (it isn't the case for your code ;) ), it =20
> 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 =20
>>>>>> asap
>>>>>> (maybe in few weeks :( )
>>>>>>
>>>>>> Emmanuel
>>>>>>
>>>>>> Rahul Thakur a =E9crit :
>>>>>>
>>>>>>> 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 =20=

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

>>>>>>> [2].
>>>>>>>
>>>>>>> 2) Refactorings to Store interface
>>>>>>> Main motivation has been to keep the core Store interface lean =20=

>>>>>>> and
>>>>>>> mean (read extensible). The Store interface[3] now has 4 =20
>>>>>>> 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 =20
>>>>>>> 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/con=
tinuum-model-jpa/src/main/java/org/apache/maven/continuum/store/api/Store.=
java
>>>>>
>>>>>>>
>>>>>>>
>>>>
>>>>
>>>
>>
>>