On Sep 12, 2006, at 4:47 PM, Chris Hostetter wrote:
: I've implemented the ability to override the default operator with
: q.op=AND|OR. The patch is pasted below for your review.
if i'm reading that right, one subtlety is that "new
SolrQueryParser(schema,field)" no longer pas attention to
sche
I probably need to visualise my models:
MobileInfo (1)(1...*) SellingItem
MobileInfo has many fields to describe the characteristics of a mobile phone
model (color, size..). SellingItem is an "instance" of MobileInfo that is
currently sold by a user. So in the
: SolrQueryParser now knows nothing about the default operator, it is
: set from QueryParsing.parseQuery() when passed a SolrParams.
i didn't test it, but it looks clean to me.
the only other thing i would do is beaf up the javadocs for
SolrQueryParser (to clarify that IndexSchema is only used f
I just pulled down the nightly solr build from 9/12 and have it up and
running. I copied an index created in a solr version that's about 3 months
old.
I have a query formulated like this:
http://solrbox:8080/solr/select?q=description:dell&rows=0&facet=true&facet.limit=-1&facet.field=merchant_nam
: I just pulled down the nightly solr build from 9/12 and have it up and
: running. I copied an index created in a solr version that's about 3 months
: old.
it looks like my changes to have a sensible default (which is when
facet.limit=-1 became legal) didn't make it into solr-2006-09-12.zip, bu
Thanks Chris.
I bumped the facet.limit to 10 and it works like a charm.
Thanks for the heads up on the merchant_name. I would probably just keep a
dictionary in memory, but if I wanted to pull the stored merchant_name back,
how would/can I do that?
thanks,
j
On 9/13/06, Chris Hostetter <[EMAI
On 9/13/06, Jeff Rodenburg <[EMAIL PROTECTED]> wrote:
Thanks for the heads up on the merchant_name. I would probably just keep a
dictionary in memory, but if I wanted to pull the stored merchant_name back,
how would/can I do that?
If you don't want merchant_name tokenized at all, just change t
Outstanding, thanks.
- j
On 9/13/06, Yonik Seeley <[EMAIL PROTECTED]> wrote:
On 9/13/06, Jeff Rodenburg <[EMAIL PROTECTED]> wrote:
> Thanks for the heads up on the merchant_name. I would probably just
keep a
> dictionary in memory, but if I wanted to pull the stored merchant_name
back,
> how
Hi all,
I just installed the nightly build to try the Faceted Searching . After some
testing I discovered that some characters are missing in the result XML and
that fields with "/" chars are sometimes split into two entries.
Example:
1 should be France
1 should be Culture/Festivals
Please f
: I just installed the nightly build to try the Faceted Searching . After
: some testing I discovered that some characters are missing in the result
: XML and that fields with "/" chars are sometimes split into two entries.
I believe what you are encountering is an issue of tokenization (or
analy
On 9/13/06, Andre Basse <[EMAIL PROTECTED]> wrote:
Example:
1 should be France
1 should be Culture/Festivals
Hi Andre,
Field faceting works over the indexed terms... so you get back what
was indexed (word splitting, lowercasing, stemming, etc... the
process is not generally reversible).
Perh
Sorry, please ignore that email. Problem solved (I should read more mails...)
Thanks to Jeff.
Hi all,
I just installed the nightly build to try the Faceted Searching . After some
testing I discovered that some characters are missing in the result XML and
that fields with "/" chars ar
You need to use an untokenized field for facets. I can see we're
going to get this question frequently now - it was mentioned earlier
today in fact. You can use a that is untokenized such
that you can use one field for searching, and one for facets.
You are obviously using a stemming ana
On Sep 13, 2006, at 9:37 PM, Chris Hostetter wrote:
http://www.nabble.com/Error-in-faceted-browsing-tf2267819.html
...i'll try to update the docs for facet.field to make this more
obvious.
Would it ever make sense to generate facets on a tokenized field?
Maybe the facet implementation co
On 9/13/06, Erik Hatcher <[EMAIL PROTECTED]> wrote:
Would it ever make sense to generate facets on a tokenized field?
Maybe the facet implementation could throw an error if the field name
specified is tokenized?
I think it probably can make sense...
- finding top terms in a full-text field that
On 9/13/06, Erik Hatcher <[EMAIL PROTECTED]> wrote:
You need to use an untokenized field for facets.
At least 3 answers in 5 minutes... we should try synchronized swimming ;-)
-Yonik
Thanks for the answer; and try to enjoy your vacation / travel! Can't
wait to be able to interface with MoreLikeThis within Solr!
Michael Imbeault
CHUL Research Center (CHUQ)
2705 boul. Laurier
Ste-Foy, QC, Canada, G1V 4G2
Tel: (418) 654-2705, Fax: (418) 654-2212
Erik Hatcher wrote:
On Sep
My index seems to be duplicating all records on insert even though I have my
add statements set to not allow duplicates.
I've provided a samle xml file of add docs. Anyone experienced this?
obituaries_
http://www.bangordailynews.com/a/class/obituaries/obituary.cfm?id=16140
20001204
In the example I sent the "id" field is not unique, but I've long since
corrected that and still getting duplication. FYI
On 9/14/06, Tim Archambault <[EMAIL PROTECTED]> wrote:
My index seems to be duplicating all records on insert even though I have
my add statements set to not allow duplicat
19 matches
Mail list logo
