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