Thanks! Now, to hunt for this in the parsers.
On 06/02/2013 09:16 PM, Israel Tsadok wrote:
You can do this with a PhraseQuery[1]. Just add more terms with position 0.
[1]
http://lucene.apache.org/core/4_3_0/core/org/apache/lucene/search/PhraseQuery.html#add(org.apache.lucene.index.Term,
int)
Hello!
I've implemented a SpanQuery class that acts like SpanPositionCheckQuery but
also matches payloads.
For example, here is the "gram" field in a single indexed document:
"gram": N|1|1sg|1|0A|2|0pl|2|0A|3|0sg|3|0
Every token's meaning is as follows:
N - grammatical annot
Hi Manoj,
This is maybe related to the compression support which was added in Lucene
4.1. Although it improves performance on large indexes, it might prove to
be slightly faster on indexes that completely fit in the file-system cache,
especially if you fetch a large number of records at each reque
On Mon, Jun 3, 2013 at 5:28 AM, Arjun Dhar wrote:
> I have a DrillDownQuery for taxonomy Search (Category path based search)
> The following works beautifully:
>
> However there is no Constructor or method arguments to allow sorting; so I
> did:
>
> ...which throws some rubbish.
I don't see any c
I have a DrillDownQuery for taxonomy Search (Category path based search)
The following works beautifully:
However there is no Constructor or method arguments to allow sorting; so I
did:
...which throws some rubbish.
I have followed all the rules for Indexing for sorting etc. (On a Numeric
Field
ok managed to FIX it! :)
Too a Q from
http://lucene.472066.n3.nabble.com/sort-by-field-and-score-td4022541.html
So without sort the code that always worked was:
Assume : facetsCollector - Defined
With Sort: (Use *TopFieldCollector*)
--
View this message in context:
http://lucene.472066.n3
Thanks
In other words does that imply "tokenized" property is ignored for Numbers?
..if so, would it be technically correct (atleast from a correctness
standpoint), to have it set as "false" in the FieldType definitions then ?
--
View this message in context:
http://lucene.472066.n3.nabble.
Ah .. Sorry i think i got it.
It is still tokenized for purposes u mentioned.
Only for sort there is an exception to the rule.
ok cool
thanks !! :)
--
View this message in context:
http://lucene.472066.n3.nabble.com/Why-Numeric-IntField-tokenized-true-by-Default-tp4067738p4067790.html
Sent fr
This is because, under the hood, a single number is indexed into
several "hierarchical" tokens, to make NumericRangeFilter/Query very
fast.
When this field is sorted, there is careful logic to use only the
original number for sorting purposes
So, it's true that in general you should not tokenize
Hi Oded,
What sort of queries are you running?
How many unique facet labels do you have (TaxonomyReader.getSize())?
Are you computing facet counts, or something more interesting (e.g.
associations)?
Any thing else "unusual" about the app? Filter, sorting, custom
collectors, etc ...
Mike McCand
I have also observed, that when using the TopDocsCollector version of the
Query, if the hits exceed the the number of actual results, it returns
nothing.
In the case of of plain .search(query, hits, sort); the damn thing keeps
going on n on. If i give an absurd number of hits, it wont stop.
--
Dear sir/madam,
I have been working with lucene 3.0.3 and wish to upgrade to lucene 4.3 but
i found the performance of 4.3. slower than 3.0.3. I have attached the
code used to test and results of test along with this mail. Is there any
specific usage pattern to be followed to improve the performa
This post was updated on Jun 03, 2013; 3:48am.
If One refers to the JavaDoc for Sort it states that INDEX and and the field
should NOT be TOKENIZED.
Its a common use case for Numbers to be Sorted.
Am curious to find the default values of say IntField as :
TYPE_NOT_STORED.setTokenized(true);
A
13 matches
Mail list logo
