You could copy the existing core to a new core every once in awhile, and
then do your delta indexing into a new core once the copy is complete. If
a Persistent URL for the search results included the name of the original
core, the results you would get from a bookmark would be stable. However,
if
bq: Also, my boss told me it unequivocally has to be this way :p
Pesky bosses .
But how often is the index changing? If you're not doing any updates
to it, then the problem is moot the other way to approach this problem
is to just control when the index changes. Would it suffice to only have
I completely agree. I would prefer to just rerun the search each time.
However, we are going to be replacing our rdb based search with something
like Solr, and the application currently behaves this way. Our users
understand that the search is essentially a snapshot (and I would guess many
prefe
No, there's nothing like that in Solr. The closest you
could come would be to not do a hard commit (openSearcher=true)
or a soft commit for a very long time. As long as neither
of these things happen, the search results won't
change. But that's a hackish solution.
In fact I question your basic ass
Hi jfeist,
Your mail reminds me this blog, not sure about solr though.
http://blog.mikemccandless.com/2011/11/searcherlifetimemanager-prevents-broken.html
From: jfeist
To: solr-user@lucene.apache.org
Sent: Friday, August 23, 2013 12:09 AM
Subject: Storing qu
