Thanks for the answers. I'll definitely change the schema, adding new fields to
improve quality of results.
In the meanwhile I cannot throw away everything, because this is a production
project. What I'm worried about is the size of this text field (about 4/5MB for
each document). How can be b
OK. I was able to get it to work by looking at {!switch} code. I had a heck
of a time trying to get parse() to work as a separate class.
q.add(new TermQuery(new Term("state", "CO"), Occur.MUST);
return q;
That never did anything.
Here is some code that worked...
http://localhost:8983/solr/provi
AFAIK your text field can be as big as your resources make possible.
The flip side is that, the bigger the field, the longer it'll take to
search, and more importantly return. If you plan on storing and returning
your entire 4/5 MB field, it is going to take you a lot of time. I mean A
LOT! For one
For those interested I created a separate jira issue for this but forgot to
attach earlier.
https://issues.apache.org/jira/browse/SOLR-8466
On Jan 2, 2016 8:45 PM, "William Bell" wrote:
> Yes we would like backward compatibility. We cannot switch all the facet
> fields to DocValues and our facet
Thanks Binoy for sharing your experience that's a good suggestion. Thank you so
much.
Ciao,
Vincenzo
--
mobile: 3498513251
skype: free.dev
> Il giorno 03 gen 2016, alle ore 14:02, Binoy Dalal
> ha scritto:
>
> AFAIK your text field can be as big as your resources make possible.
> The flip s
Sorry Upayavira, I didn't see your question. This collection is used to search
and retrieve the document if there is whatever matching query. I'm not sure if
the entire document is returned or if the big text field is used only to search
and return some ids, I have to investigate.
Ciao,
Vincen
I haven’t fully digested this thread, but wanted to comment on this one.
¶m=$something doesn’t substitute. Only “local” params (inside local param
syntax curly brackets) do that. If you want to substitute a raw parameter use
curly brackets. You could, in this example, use &tt=${state1}, I be
Thanks that indeed works tt=${state1}. But that was just a passing question.
I see an empty "*case*", "default" and a "case.VAL". I think I have
anything I need. After rereading. We might want to add to "case.VAL"
something like "case.'state:CO'" with a single quote. Right now it does not
appear t
Interesting that facet.method=dv or facet.method=uif. What is the
difference?
On Sun, Jan 3, 2016 at 6:44 AM, Jamie Johnson wrote:
> For those interested I created a separate jira issue for this but forgot to
> attach earlier.
>
> https://issues.apache.org/jira/browse/SOLR-8466
> On Jan 2, 2016
The patch adds facet.method=uif and then delegates all of the work to the
JSON Faceting API to do the work. I had originally added a facet.method=dv
and made the original facet.method=fc work using the UnInvertedField but
wanted to avoid making a change that would introduce unexpected behavior.
Wh
Ok the path appears to have dv and uif in there.?
On Sun, Jan 3, 2016 at 4:40 PM, Jamie Johnson wrote:
> The patch adds facet.method=uif and then delegates all of the work to the
> JSON Faceting API to do the work. I had originally added a facet.method=dv
> and made the original facet.method=fc
Thanks for the reply Shawn and Erick.
What *exactly* are you looking at that says Solr is using all your
memory? You must be extremely specific when answering this question.
This will determine whether we should be looking for a bug or not.
A) Before I start the optimization, the server's memory
Are you looking at 8466 or 8096? The patch on 8466 is the one I'm
referencing. I should remove the other as it is more change than I think
should be done for this ticket.
Jamie
On Jan 3, 2016 8:47 PM, "William Bell" wrote:
> Ok the path appears to have dv and uif in there.?
>
> On Sun, Jan 3,
13 matches
Mail list logo
