Re: Faceted search glitch???
On 2/9/07, Erik Hatcher <[EMAIL PROTECTED]> wrote: On Feb 9, 2007, at 9:16 PM, Mike Klaas wrote: > Might I suggest: > > filter.query > filter.term > filter. I like it. While Hoss has a point, though descriptive names do make a lot of sense too. It has been a bit confusing to explain facet.query and fq as two different things. I like self-documenting parameter names, but if there is concern about verbosity, how 'bout: fq fq.term (also, filter.q could be used in the longer version). As for future expansion, some possibilities are: filter.op/filter.q.op (set operator of filter query parser, which is currently OR regardless of the solrconfig setting), filter.range, and filter.q.noncached (something I would definitely use if it existed). However, is there any concern, at all, about the added overhead in passing larger requests around? I would guess that the difference would be impossible to measure, but I don't really know. -Mike
Re: Faceted search glitch???
: > > filter.query : > > filter.term : > > filter. : I like self-documenting parameter names, but if there is concern about : verbosity, how 'bout: : : fq : fq.term no it's cool ... filter.query and filter.term are definitely better. : As for future expansion, some possibilities are: filter.op/filter.q.op : (set operator of filter query parser, which is currently OR regardless I'm not sure why/how thta would ever make sense... you'd be much better off using seperate filters so they can cache independently - not to mention the reason q.op was added was for dealing with user entered query strings, but are filter queries ever entered manually by a user? : of the solrconfig setting), filter.range, and filter.q.noncached : (something I would definitely use if it existed). filter range could just be done with a filter.query/fq right? a non-cached fq might make sense though. -Hoss
Re: search including single quote fails in SOLR, only when sorting!?
I applied the patch here (split_sort.txt) https://issues.apache.org/jira/browse/SOLR-140 I then recompiled this version: apache-solr-1.1.0-incubating using: ant compile then ant dist I then copied: /opt/apache-solr-1.1.0-incubating/dist/apache-solr-1.1.1-dev-incubating.war as solr.war, and deployed it via tomcat. Unfortunately, i could not find any differences in behaviour. If I search for anything, and add a 's (apostrophe s) AND use a sort (i.e., ;price or whatever) it returns me no hits. I did notice that with both pre and post patched .war file, if you use an escape char (as u recommended) i.e., \'s it will work. Maybe i didn't do something right, not sure. Thanks for the patch though, let me know if you would like me to try another. Thx J On 2/4/07, John Kleven <[EMAIL PROTECTED]> wrote: Thanks for the response. JIRA issue opened. http://issues.apache.org/jira/browse/SOLR-140 J On 2/2/07, Yonik Seeley <[EMAIL PROTECTED]> wrote: > > Hmmm, Solr tries to be smart about splitting the query from the sort > specification. > If it sees a semicolon inside quotes (single or double), or backslash > escaped, then it will treat it as part of the query. > > An immediate workaround would be to query for "jam's" or jam\'s > > It would be helpful if you could open a JIRA issue for this. > > -Yonik > > On 2/2/07, John Kleven < [EMAIL PROTECTED]> wrote: > > Search for the word jam's -- including the single quote. (%27 is a > single > > quote encoded for URL) > > > > Here's the examples > > http://10.0.101.11:8080/forsale/select/?q=jam%27s-- this works (i > get > > ~20 hits back) > > http://10.0.101.11:8080/forsale/select/?q=jam%27s;score%20desc --- > this > > doesn't (get 0 hits back) > > > > > > Seems that if the first query works, it shouldn't be breakable just by > > telling it explicitly to sort on score?? All other sorts break in > this > > scenario as well (i.e., price, etc). > > > > Also, if i just search jam (and ditch the 's) then I AM able to > sort. I'm > > using the standard tokenizer/filter, and stemming, so it always comes > down > > to just jam anyways. But w/ the quote, it cannot be sorted. Strange. > > > > Ideas? Sorry if this is too vague or has already been posted. > > > > j >
Re: Faceted search glitch???
On 2/10/07, Chris Hostetter <[EMAIL PROTECTED]> wrote: : As for future expansion, some possibilities are: filter.op/filter.q.op : (set operator of filter query parser, which is currently OR regardless I'm not sure why/how thta would ever make sense... you'd be much better off using seperate filters so they can cache independently - not to mention the reason q.op was added was for dealing with user entered query strings, but are filter queries ever entered manually by a user? See below. : of the solrconfig setting), filter.range, and filter.q.noncached : (something I would definitely use if it existed). filter range could just be done with a filter.query/fq right? a It sure could, but I was just trying to stretch my imagination as far as possible. filter.term also seems to me like only a marginal improvement over lucene syntax. -Mike
Dynamic Result Grouping
The feature list included in the Solr website says solr provides "Support for Dynamic Result Grouping". I can't find any documentation on the website explaining what this is, or how one would go about using it. Anyone care to enlighten me?
Re: Dynamic Result Grouping
On 2/11/07, Brendan Ribera <[EMAIL PROTECTED]> wrote: The feature list included in the Solr website says solr provides "Support for Dynamic Result Grouping". It's faceting (grouping by field value dynamically). I later learned that people commonly use "grouping" in a different sense, so it's probably misleading. -Yonik
Re: Faceted search glitch???
: It sure could, but I was just trying to stretch my imagination as far : as possible. filter.term also seems to me like only a marginal : improvement over lucene syntax. the only reason i suggested filter.term at all was because it eliminates hte need to worry baout quoting/escaping when dealing with simple term based facets ... right now you have to put the facet term in quotes (inlcuding posisble quote escaping) ... if we add a filter.term param you can write client code that is blindly ignorant of what facet constraint is being filtered on. -Hoss
