The best we currently have is to add debugQuery=true to the request - that will return what the actual Lucene query looks like (stemmed forms, expanded fields, etc).
-Yonik http://www.lucidimagination.com On Mon, Jun 1, 2009 at 12:56 PM, Mark Bennett <[email protected]> wrote: > Using nightly builds. (actually May 4th...) > > When things go OK one of the options you can enable is to see the fully > expanded query in the search results. > > But I have a custom schema, and clearly there's something in the dismax > logic that clashes with it. > > This would normally be easy to fix, by looking at the expanded query in the > web UI and then making the appropriate changes, but the error seems to short > circuit getting back the results list, which would have shown the query. > > What I'd really like is just a "testqp" utility, like Verity K2 used to > have: > * select the parser (or search component, etc) > * type in a "user" query > * see the fully expanded parse tree (without actually running the search) > * that old tool also ran from the command line, which was nice, though at > this point web or console would be OK > > Though I suspect I could eventually extract this logic from the code base > myself, I'm not as familiar with this code base as y'all, and decided to > sacrifice my pride for expediency in this particular case. :-) I have made > some progress on extracting other bits of code. > > I suppose there is some possibility, depending on how it's written, that > dismax CAN'T generate a fully expanded query if there's any problem with the > schema. In that case I guess an (English) explanation of what dismax does > in terms of query generation would be the backup plan. I've certainly > looked around at the doc for dismax. There's a lot of "how to use it", what > the options are, etc. But what I really wanted was to understand its query > generation logic, so that I could adapt it to my project. > > Thanks in advance, > Mark > > -- > Mark Bennett / New Idea Engineering, Inc. / [email protected] >
