thanks a lot for your answer
i find the second way may be useful to me. it is new to me and i will
try it.
thanks
andrew
在 2015/2/11 21:39, Ian Lea 写道:
If you only ever want to retrieve based on exact match you could index
the name field using org.apache.lucene.document.StringField. Do be
a
I have a class that extends FilterCodec. Written against Lucene 4.9,
it uses the Lucene49Codec.
Dropped into a copy of Solr with Lucene 4.10, it discovers that this
codec is read-only in 4.10. Is there some way to code one of these to
get 'the default codec' and not have to chase versions?
--
Thank you Uwe!
Your reply is very useful and insightful. Your workflow matches my
requirements exactly.
My confusion was coming from the fact that I didn't understand what the
Analyzers are doing. Actually I am still wondering, isn't it possible to
provide an abstraction on Lucene side to make th
No, because you only looked into one bug. We have seen and do so see
many G1 related test failures, including latest 1.8.0 update 40 early
access editions. These include things like corruption.
I added this message with *every intention* to scare away users,
because I don't want them having index
fellas,
I am wondering if it is possible to wrap payload query with
customscorequery, so that one can tweak the search score with both payload
similarity and a customized score provider? This is useful in that one
might want to boost the score at token level (attached with payload) as
well as at t
Hi,
A couple mailing list members have brought the following paragraph from the
https://wiki.apache.org/lucene-java/JavaBugs page to my attention:
"Do not, under any circumstances, run Lucene with the G1 garbage collector.
Lucene's test suite fails with the G1 garbage collector on a regular bas
An example why you might do this is if your input is a term vector (ie
a list of unique terms with weights) rather than a text in the usual
sense. It does seem as if the best way forward in this case is to
generate a text with repeated terms. I looked at the alternative and it
is quite invol
many thanks. the understanding of the meaning of BooleanClause.Occur.SHOULD
was my problem.
now the query works as expected.
greetings
Sascha
Gesendet: Dienstag, 10. Februar 2015 um 21:17 Uhr
Von: "Ian Lea"
An: java-user@lucene.apache.org
Betreff: Re: Re: combine to MultiTermQuery with O
In my case, for any non-trivial search, I always build a boolean query
with relevant parsing for each field, where applicable using something
like oal.queryparser.classic.QueryParser.
So if I had some free text docs with a date field, the latter stored
as you suggest, and a query along the lines o
Ok... so how does anyone ever use date-time queries in lucene with the
new recommended way of using longs?
Jon
On Wed, Feb 11, 2015 at 9:26 AM, Ian Lea wrote:
> Ah well, you've got me there. I'm not a lucene developer and rather
> thought that I'd leave the implementation as an exercise for t
Ah well, you've got me there. I'm not a lucene developer and rather
thought that I'd leave the implementation as an exercise for the
reader. Good luck!
--
Ian.
On Wed, Feb 11, 2015 at 2:20 PM, Jon Stewart
wrote:
> Eek. So is there a parsing component somewhere that gets handed a
> field name
Eek. So is there a parsing component somewhere that gets handed a
field name and query components (e.g., "created", "2010-01-01",
"2014-12-31"), which I can derive from, parse the timestamp strings,
and then turn the whole thing into a numeric range query component?
Jon
On Wed, Feb 11, 2015 at
To the best of my knowledge you are spot on with everything you say,
except that the component to parse the strings doesn't exist. I
suspect that a contribution to add that to StandardQueryParser might
well be accepted.
--
Ian.
On Wed, Feb 11, 2015 at 4:21 AM, Jon Stewart
wrote:
> Hello,
>
>
If you only ever want to retrieve based on exact match you could index
the name field using org.apache.lucene.document.StringField. Do be
aware that it is exact: if you do nothing else, a search for "a" will
not match "A" or "A ".
Or you could so something with start and end markers e.g. index yo
You could consider payloads but why do you want to do this?
What's the use case here? Sounds a little like an XY problem, you're
asking us how to do something without explaining the why; there
may be other ways to accomplish your task.
For instance, there's the "termfreq" function, which an be ret
Hi,
I would like to index documents which contain term frequencies instead of
the actual text. For example, instead of getting "The big wolf ate the big
sheep" I would get "the|2 big|2 wolf|1 ate|1 sheep|1". An easy way to index
this would be to convert the frequencies back into text, so into some
Lucene is agnostic to how (database or not) your content is stored
externally: it's up to you to pull that content out, make Documents
and index them into Lucene.
It is not a great idea to store a Lucene index in a database...
Also, Compass essentially became Elasticsearch.
Mike McCandless
http
Hi,
This is a question to confirm my understanding of lucene when used
along with databases and clear my doubts. Lucene can be used to read from
databases(both sql and nosql) but there is no api that supports it.
Is there any database that is preferred over other databases for use along
with
18 matches
Mail list logo
