[Xapian-discuss] Re: 1.0 news, and a call for testing

[Fabrice Colin]

On 5/6/07, Fabrice Colin <fabrice.colin at gmail.com> wrote:
> On 5/6/07, Richard Boulton <richard at lemurconsulting.com> wrote:
> > That seems like a reasonable suggestion to me.  We want to avoid forcing
> > application writers to parse error messages - it's quite reasonable that
> > they might want to handle this case differently to any other
> > DatabaseOpeningError - for example, if they have the source data
> > available still, the application could automatically start rebuilding
> > the database, so that software upgrades can work without human
> > intervention.
> >
> That's exactly what I had in mind :-)
>
On the same subject, I am experiencing a problem with locking.
The sequence of events is as follows :
1. make sure no process uses the index I want to open (created with 0.9.x)
    and that neither "flintlock" nor "flicklock" exist.
2. create a WritableDatabase object with
    Xapian::WritableDatabase(path_to_the_index, Xapian::DB_CREATE_OR_OPEN)
3. catch DatabaseOpeningError exception, check that the message is about the
   version of Flint
4. try to overwrite the index with
     Xapian::WritableDatabase(path_to_the_index, Xapian::DB_CREATE_OR_OVERWRITE)

At step 3, flintlock exists, thus preventing step 4 which results in a
DatabaseLockError
("Unable to acquire database write lock on
/home/fabrice/.pinot/daemon: already locked").
Am I right in thinking that the lock file should be removed before
DatabaseOpeningError
is thrown ?

Cheers.

Fabrice