Hmmm, you might want to move this over to the Solr user's list. This list
is lucene, which doesn't have anything to do with post.jar ;)...
On Fri, May 30, 2014 at 8:25 AM, Erick Erickson
wrote:
> Try a cURL statement like:
>
> curl "
> http://localhost:8983/solr/update/extract?literal.id=doc33&
If you do an optimize, btw, the internal doc IDs may change.
But _why_ do you want to keep them? You may have very good reasons, but
it's not clear that this is necessary/desirable from what you've said so
far...
Best,
Erick
On Fri, May 30, 2014 at 7:49 AM, Nicola Buso wrote:
> Hi,
>
> th
Try a cURL statement like:
curl "
http://localhost:8983/solr/update/extract?literal.id=doc33&captureAttr=true&defaultField=text";
-F "myfile=@testRTFVarious.rtf
first, then work up to the post.jar bits...
Two cautions:
1> make sure to commit afterwards. Something like
http://localhost:8983/s
Hi,
thanks Michael and Alan. Is enough to know that re-opening the index
there is no guarantee that the docids are maintained also if the index
does not change.
And I will try the question also on the Solr mailinglist.
nicola.
On Fri, 2014-05-30 at 10:41 -0400, Michael Sokolov wrote:
> There
There is a Solr document cache that holds field values too, see:
http://wiki.apache.org/solr/SolrCaching
Maybe take this question over to the solr mailing list?
-Mike
On 5/30/2014 10:32 AM, Alan Woodward wrote:
Solr caches hold lucene docids, which are invalidated every time a new searcher
i
Hi ,
Finally I have been able to convince my team to go for indexing all documents
first and then search rather than do on the fly indexing. I have set up Solr on
my machine but unable to index RTF'f. I have followed the tutorial..but no
where RTF is mentioned..Can someone please help me..
I tr
Solr caches hold lucene docids, which are invalidated every time a new searcher
is opened. The various fields for a response aren't cached as far as I know,
they're reloaded on each request. But loading the fields for 10 documents is
typically very fast, compared to searching over a very large
Hi Alan,
just to make it more typical (yes there are not IndexWriters open on
that indexes) how solr is caching results? the first thing I would like
to do is to store the docs ids and return to the reader for the real
content. Is solr storing the whole results with all values?
nicola.
On Fri,
If the index is truly unchanging (ie there's no IndexWriter open on it) then I
guess the document numbers will be stable across reopens. But this is a pretty
specialized situation, and the docs are really there to warn you off trying to
rely on this for more typical uses.
Alan Woodward
www.fla
Hi Alan,
thanks a lot for the reply.
For what I understood from your reply if the index is not changing (no
adds, deletes even updates) the docs id viewed by the MultiReader will
not change if you open more times that unchanged index also in different
environments.
If this is true (my understand
I put a comment on the StackOverflow question.
Mike McCandless
http://blog.mikemccandless.com
On Fri, May 30, 2014 at 2:51 AM, Gaurav gupta
wrote:
> Hi,
>
> I am implementing NRT and looking for best practice to implement it. I
> found that 4.4.0 release onwards the Near Real Time Manager
> (o
Hi Nicola,
1) A session here means as long as you have that MultiReader open.
IndexReaders see a snapshot of the index and so document ids shouldn't change
over the lifetime of an IndexReader, even if the index is being updated.
2) MultiReader just takes an array of subindexes, so as long as t
Thanks Xiaolong. Really the item 5 is helpful.
-Original Message-
From: Xiaolong Zheng [mailto:xiaolong.zh...@mathworks.com]
Sent: Thursday, May 29, 2014 8:44 PM
To: java-user@lucene.apache.org
Subject: Re: Lucene Upgrade from 2.9.x to 4.7.x
I just upgrade Lucene from 2.0.0 to 4.6.1, he
13 matches
Mail list logo
