I did a little bit of work on the SQL 2 parsing and executing, and really the parsing time is insignificant. The real time is spent executing the queries, so SQL 2 vs QOM is not really a bit issue.
But it's much easier to build QOM programmatically, especially if you need to modify queries dynamically. On the other side SQL-2 is really great to work with for everything else :) cheers, Serge... On 10 août 2011, at 22:56, Alex Parvulescu wrote: > Hi Stephen, > > If you use SQL2 then you'll have to accept the penalty of parsing the query > to a QueryObjectModel. But I'd say this is not the biggest problem you'll > run into. > Doesn't this fall into the premature optimization category? ;) > > I think the better part of the work will go into optimizing the actual > query. > > You can profile the parsing code, for your own piece of mind [0], maybe it > will give you some comfort. Look at #createQueryObjectModel(String query) > > best, > alex > > [0] > http://svn.apache.org/viewvc/jackrabbit/trunk/jackrabbit-jcr-commons/src/main/java/org/apache/jackrabbit/commons/query/sql2/Parser.java?view=markup > > > On Wed, Aug 10, 2011 at 5:45 PM, Stephen Byrne <[email protected]> wrote: > >> I have an application specific model in my Jackrabbit repository and have >> to dynamically generate JCR queries from an application specific search >> syntax. Am I better off performance-wise having my code build the QOM tree >> than generating SQL2? >> >> If I use SQL2 (or XPath), Jackrabbit takes that statement and generates a >> QOM tree, right? >> >> -- >> Stephen Byrne >> LincWare, LLC >> [email protected] >>
