[Xapian-discuss] TCL Binding working, but db_lock doesn't get removed?

[Eric Parusel]

Olly Betts wrote:
>>Is there a particular way I should be destroying the WritableDatabase 
>>object?
>  
> For Tcl, I really don't know - sorry!  Perhaps Michael will be able to
> suggest something.
> 
> It's not just the lock file - unless you explicitly flush before the
> script exits, you're rely on the destructor to flush the last batch
> of changes.

Ok, I did find that I had to "db flush" for the document to be added...
(I was printing out the document count much like the tcl examples posted 
to the list)

I did try "db -destroy" at the end of my test script (which ran without 
errors) -- however the lock file stayed put...
I read somewhere that -destroy would get rid of the object... *shrug*

I suppose that even if the db_lock file normally was removed, in the 
event of a sudden reboot it would be possible the db_lock file would 
still be present?  Which would lock the db from writes?
If so, this is probably acceptable, rarely will we be getting unexpected 
shutdown -- the indexing app would end up notifying me.
I'd just have to remove the lock file to resume indexing...

I do suppose that multiple writers (no write lock) is out of the 
question?  (easier said than done I'm sure :) )


> Any positive unsigned 32 bit integer is fine (0 isn't).
> 
> The compression schemes used in the tables assume the docids aren't
> sparse.  Something like an auto-incrementing uid field from a SQL
> database should work well.  Something like using document hashes or
> machine IP addresses as the docids probably wouldn't (although there's
> also overhead for storing and using a UID term...)

Ok, it is based off of a pgsql sequence, starting from 1, incrementing.
Very rarely will there be an unassigned id. (failed db transaction, 
possibly, I think)

Thanks once again,
Eric