Yeah, I ended up not modifying the base query object. But now that the querybuilder is complete we could go back and modify access or provide access methods for those variables.
On Thu, Dec 4, 2014 at 4:00 PM, Claude Warren <[email protected]> wrote: > You could call build them in static and then call clone(). > > Then you can set values and what not without influencing the next usage. > > On Thu, Dec 4, 2014 at 3:40 PM, Kristian Rosenvold > <[email protected]> wrote: >> Thanks for the tip, and I find myself slightly amused at a >> querybuilder that calls setVisible on member variables within jena >> itself :) So much for "can't be done". >> >> It would appear this actually does some of what I'm looking for; it >> makes it somewhat less CPU intensive to construct query objects. >> They're still not reusable, but I assume I'd be able to put a bunch of >> different "SelectBuilders" in static scope somewhere and repeatedly >> call "build" on that instead. I'll see how that stacks up. >> >> Thanks >> >> Kristian >> >> >> 2014-12-04 16:08 GMT+01:00 Claude Warren <[email protected]>: >>> Not sure if this will solve all the problems but have you looked at >>> the QueryBuilder? >>> >>> http://jena.apache.org/documentation/extras/querybuilder/index.html >>> >>> I would be interested to know how it stacks up against your >>> performance requirements. >>> >>> Claude >>> >>> On Thu, Dec 4, 2014 at 3:01 PM, Kristian Rosenvold >>> <[email protected]> wrote: >>>> We have been troubled by lots of overhead for SPARQL parsing in our >>>> code base, and I have been looking for something like the >>>> "preparedstatement" of sql with the ability to pre-interpret the >>>> statement and set parameters upon execution. Digging around on QA >>>> sites and in the code base I have come up with the following code: >>>> >>>> private static final Query q1template = .. create query with ?param >>>> expression... >>>> ... >>>> QuerySolutionMap params = new QuerySolutionMap(); >>>> params.add("param", myresource); >>>> QueryExecution exec = QueryExecutionFactory.create(q1template, >>>> model,params); >>>> >>>> This doubled the speed of our code, since the SPARQL parsing is pretty >>>> heavy and can be made a "constant" part like an sql preparedstatement. >>>> >>>> Now this does not really work, since there is mutable state in >>>> q1template and it can't be shared (it fails in setResultVars >>>> intermittently - and possibly other places too). Looking at the code >>>> base I see that there seem to be several potential gotchas that are >>>> probably lurking right under the hood, there are too many per-request >>>> bits and pieces of state that are kept in the Query. >>>> >>>> Not giving up that easily, I created the following method: >>>> >>>> public static Query copyOf(Query query){ >>>> Query copy = new Query(query); >>>> copy.setQueryPattern(query.getQueryPattern()); >>>> if ( query.isSelectType()) copy.setQuerySelectType(); >>>> else if (query.isAskType()) copy.setQueryAskType(); >>>> else if (query.isConstructType()) copy.setQueryConstructType(); >>>> else if (query.isDescribeType()) copy.setQueryDescribeType(); >>>> >>>> if (query.hasOrderBy()){ >>>> for (SortCondition sortCondition : query.getOrderBy()) { >>>> copy.addOrderBy(sortCondition); >>>> } >>>> } >>>> return copy; >>>> } >>>> >>>> >>>> And now I can seemingly use >>>> >>>> QueryExecution exec = QueryExecutionFactory.create(copyOf(q1template), >>>> model,params); >>>> >>>> and actually get this working concurrently with re-use of the parsed >>>> sparql expression. But of course there's ElementSubQuery pointing back >>>> at the Query object, so a deep copy of the queryPattern Element >>>> structure would probably also be required, which all seems a bit like >>>> barking up the wrong tree. And I'm not really sure I understand all >>>> the cross-references well enough to know that this would even >>>> work....(?) >>>> >>>> It would seem to me that the "clean" thing to do would be to separate >>>> the parsed sparql from the per-request state. By simple name it would >>>> sound like "QueryExecution" would be a nice place for these things. >>>> Would this work, is it a good idea ? >>>> >>>> Alternately (and much simpler), one could simply make a "reset" method >>>> on the Query object and accept sequential re-use. In that way I could >>>> use ThreadLocals to keep one instance of the query per thread and >>>> reduce the overall sparql parsing. >>>> >>>> I'm sort of digging a bit for suggestions/ideas here, since I'm not >>>> all that familiar with the code base :) We're talking about a fairly >>>> heavy CO2 footprint in terms of energy expenditure for repeated >>>> parsing of all that sparql :) >>>> >>>> (Initially I adressed this to the "users" list but I sort of changed >>>> my mind as the details got gorier and gorier....) >>>> >>>> Kristian >>> >>> >>> >>> -- >>> I like: Like Like - The likeliest place on the web >>> LinkedIn: http://www.linkedin.com/in/claudewarren > > > > -- > I like: Like Like - The likeliest place on the web > LinkedIn: http://www.linkedin.com/in/claudewarren -- I like: Like Like - The likeliest place on the web LinkedIn: http://www.linkedin.com/in/claudewarren
