Hoss, thanks for your feedback. I was was just a bit surprised to see that I had to go from objects to a string-rep.
I did indeed also find out that some information was lost in that process, for instance setMinimumNumberShouldMatch on BooleanQuery. Also, some empty clauses (which was silently accepted by lucene) rendered as "()" which did not seem to be parsable on the solr-side. In other words, nothing I couln't workaround. Good to know about the extension points though. Tobias 2008/8/30 Chris Hostetter <[EMAIL PROTECTED]> > > : Rephrasing: I do realize that I would be able to "flatten" my Lucene > : Query-object to its String-representation and possibly use that as a > query > : input to SolrQuery. But would that work for all queries ... or is the > Lucene > : object-representation more expressive (i.e. richer) than the string-rep? > > "Query" as an abstract class supports all sorts of concrete subclasses -- > not all of which can be expressed as simple strings parsable by a query > parser. but that doesn't mean all of the types of queries you currently > use can't be expressed as a string -- we'd need more info about what > exactly your "rather intricate query" looks like to give you a good answer > to that part. > > In general, anything you can do with Lucene directly can be done with Solr > -- if you write a Solr plugin for handling it. you could for example > wrote a QParser that takes in whatever input your current code parses and > then generates your complex query. > > > > -Hoss > >
