Josh Rabinowitz wrote on 10/19/2009 02:07 PM:
> Since replacing indexes is what Swish-e 2.4 does
> 'by default', the least surprising thing would be
> for 2.6 to do the same.
I thought that too. Until I ran what I thought was an update on an index
via the -S prog headers and realized I had just erased my multi-gig
index in a single swipe because I needed to both pass -u *and* put the
Update-Mode in the headers.
Now *that* was surprising.
Working on swish_xapian offered me a peek at How The Other Guys Do It.
Xapian uses a directory, and they default to update_or_create rather
than replace mode.
Plus I wonder about
> concurrency issues when updating indexes in live
> use... has that åbeen tested? Is it expected to
> work well in that scenario? Overall I'd lean
> towards keeping 'replace' the default.
the concurrency issue hasn't been addressed afaik. BDB has some
transaction/locking features but they do not seem to be exercised in the
2.6 code presently.
I plan to work up some (failing) tests in Swishetest to cover this
>> (2) there are now many (6) files associated with a single index.
>> Suggestion: make the index a directory instead of a file, so you would
>> run like:
>> swish-e -f path/to/index.swish-e
>> but index.swish-e is a directory, not a file.
> (*) The least surprising thing (the thing most
> like what Swish-e does) would be to give one of
> the files (say, what's currently the
> yourname.swish-e.head file) the exact name they
> specified, and append suffixes to the others.
The approach I'm taking right now with 2.6 is to try and make it an
upgrade path to Swish3. Since Swish3 has multiple, optional backends,
some of which use a directory to hold index files (like xapian and
lucene) and some do not, Swish3 always assumes a directory. So it seemed
like a decent transition feature to do the same in 2.6.
Peter Karman . http://peknet.com/ . peter(at)not-real.peknet.com
Users mailing list
Received on Mon Oct 19 15:25:25 2009