All,
Sorry, but I inadvertenly put my post re MultiFieldQueryParser in the wrong
thread (wrong subject via cut and paste).
Igor, thank you for the reply. I will look into what you suggest.
-Paul
On Wed, Apr 3, 2013 at 6:58 AM, Igor Shalyminov
wrote:
> I personally use SpanNearQuey (span posit
uestion is how do you want to access the data? What do you want
> your queries to look like?
>
> What is the larger context? Are these properties of larger documents? Are
> there more than one per document? Etc.
>
> Why not just store the property as a tokenized field? Then you can
ord value pairs.
>
> And if you can denormalize your data, storing structure as separate
> documents can make sense and support more powerful queries. Although the
> join capabilities are rather limited.
>
>
> -- Jack Krupansky
>
> -Original Message- From: Pau
Hi All,
Suppose I need to index a property whose value is a long list of terms. For
example,
someProperty = ["v1", "v2", , "v100"]
Please note that I could drop the leading "v" and index these as numbers
instead of strings.
But the question is what's the best practice in Lucene whe
Hi,
I've done a few experiments in Lucene 4.2 with several different query
types:
TermQuery
TermRangeQuery
NumericRangeQuery
WildcardQuery
PrefixQuery
MatchAllDocsQuery
I think I more or less understand their behavior.
But I'm missing something obvious: how does one do "not equal" type
queries?
about?
-Paul
On Wed, Mar 27, 2013 at 8:12 PM, Adrien Grand wrote:
> On Wed, Mar 27, 2013 at 9:04 PM, Paul Bell wrote:
> > Thanks Adrien.
> >
> > I've scraped together a simple program in the Lucene 4.2 idiom (see
> below).
> > Does this illustrate what you
c.add(strField);
TextField txtField = new TextField("content", content,
Field.Store.YES);
doc.add(txtField);
return doc;
}
}
On Wed, Mar 27, 2013 at 11:37 AM, Adrien Grand wrote:
> Hi Paul,
>
> On Wed, Mar 27, 2013 at 1:58 PM, Paul Bell wrote:
>
Thanks, Sashidar.
In response to your "P.S.", you raise a reasonable point. I agree that it
would probably be a vain undertaking to try to keep the search index in
real-time sync with the database. I suppose this relationship is rooted in
something like the application's SLA, e.g., "query results
