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
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
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
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
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 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
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
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
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
: 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
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
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
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
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
: 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
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
: 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 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
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
19 matches
Mail list logo
