Xapian discuss - Mar 2007 - Opening/closing indexes - upgrading to write index ?

Hi all,

Just wondering if it's possible to upgrade a read-only index/DB handle to a
writeable one ?  Or if I need to close the index and open it again ?  Also if
the reverse is true. Can I downgrade a writeable index to a read-only one ?  Or
is it a matter of just reopening the index again ?

I'm doing all this in Perl and trying to call the close() method on the
index, but nothing happens. I think the writeable index always seems to leave a
lock file around because maybe the object isn't properly destructing....
>joss


	
	
		
___________________________________________________________ 
New Yahoo! Mail is the ultimate force in competitive emailing. Find out more at
the Yahoo! Mail Championships. Plus: play games and win prizes.
http://uk.rd.yahoo.com/evt=44106/*http://mail.yahoo.net/uk

On Thu, Mar 01, 2007 at 11:39:10AM +0000, Joss Shaw
wrote:
> Just wondering if it's possible to upgrade a read-only index/DB handle
> to a writeable one ?  Or if I need to close the index and open it
> again ?
No, and yes.
> Also if the reverse is true. Can I downgrade a writeable
> index to a read-only one ?  Or is it a matter of just reopening the
> index again ?
WritableDatabase is a subclass of Database, so you can pass a
WritableDatabase object whereever a Database object is expected.
But you can't actually change its class, so it remains a
WritableDatabase inside.

Provided all pending changes have been flushed, there's little
overhead in using a WritableDatabase in this way (if there are
pending changes, some operations require us to merge the pending
changes with the underlying data on the fly).
> I'm doing all this in Perl and trying to call the close() method on
> the index, but nothing happens.
There is no close() method (though there is a plan to add one).
Just assign "undef" and the referencing counting should take care of
closing it:

    $writabledatabase = undef;
> I think the writeable index always seems to leave a lock file around
> because maybe the object isn't properly destructing....
What happens on script exit if there's a live WritableDatabase
is down to Perl - if it calls destructors, the index will be flushed
and closed.  If not, changes since the last (implicit or explicit) call
to flush() will be lost (and for a Quartz database the lock file won't
get cleaned up).

Cheers,
    Olly