Problems with index in Whoosh

228 views
Skip to first unread message

Sandra Django

unread,
Jul 3, 2009, 10:30:43 AM7/3/09
to who...@googlegroups.com
Hello friends, I have a problem. I have installed Whoosh in Linux, and I want to integrate it with Django. I did everything that I show here: http://www.arnebrodowski.de/blog/add-full-text-search-to-your-django-project-with-whoosh.html and apparently the problem is Whoosh, when index, because the error is the follows: EmptyIndexError in the "search" method.
Also, in "views.py" of Django: ix = index.open_dir(settings.WHOOSH_INDEX) (an error)
When I saw my Whoosh index folder, it only had one file named _MAIN_0.toc, but I couldn't open it.
Someone knows which is my problem? Someone could help me?
Thanks,
Sandra

Note: I don't speak English, sorry if I made a mistake.

Arne

unread,
Jul 3, 2009, 3:46:56 PM7/3/09
to Whoosh
On Jul 3, 4:30 pm, Sandra Django <sandradja...@gmail.com> wrote:
> Hello friends, I have a problem. I have installed Whoosh in Linux, and I
> want to integrate it with Django. I did everything that I show here:http://www.arnebrodowski.de/blog/add-full-text-search-to-your-django-...
> apparently the problem is Whoosh, when index, because the error is the
> follows: EmptyIndexError in the "search" method.
> Also, in "views.py" of Django: ix = index.open_dir(settings.WHOOSH_INDEX)
> (an error)
> When I saw my Whoosh index folder, it only had one file named _MAIN_0.toc,
> but I couldn't open it.
> Someone knows which is my problem? Someone could help me?
> Thanks,
> Sandra
>
> Note: I don't speak English, sorry if I made a mistake.

The Whoosh Index is created at the time you run "python manage.py
syncdb" in your Django-project.

Have you executed manage.py syncdb at least once after adding the code
from the blog post?

- Arne

Sandra Django

unread,
Jul 6, 2009, 10:54:23 AM7/6/09
to who...@googlegroups.com
Thank's Arne.
Yes, I executed manage.py syncdb after adding the code. Then, now, when I add, for example, an descriptor (it's a class of my model), I get this error:
[Errno 17] File exists: '/home/sandra/Desktop/whoosh/testing/_MAIN_LOCK'

Where whoosh is the my index folder. I think that for that reason, the index couldn't be updated. Also, I get an error in __init__.py, in my search app, where I defined create_index and update_index functions. Specifically the error is in line 3.), in update_index function:

1.  storage = store.FileStorage(settings.WHOOSH_INDEX)
2.  ix = index.Index(storage, schema=WHOOSH_SCHEMA)
3.  writer = ix.writer() #Here is the problem

Please, help me. I don't understand why this problem.
Thank's,
Sandra

Matt Chaput

unread,
Jul 6, 2009, 11:42:30 AM7/6/09
to who...@googlegroups.com
> *[Errno 17] File exists: '/home/sandra/Desktop/whoosh/testing/_MAIN_LOCK'*

I can't comment on the much else, but this indicates that the index was
left in a locked state, probably because of an error in the middle of
writing. Just delete the _MAIN_LOCK directory.

Cheers,

Matt

Andrew MacKinlay

unread,
Jul 13, 2009, 9:35:51 AM7/13/09
to who...@googlegroups.com


On the subject of that, have you considered updating the
ContextManager code in writing.py to clean up after itself more
thoroughly if exceptions occur during commit? i.e.

def __exit__(self, exc_type, exc_val, exc_tb):
if exc_type:
self.cancel()
else:
try:
self.commit()
except Exception:
self.cancel() #error during commit -- we should
unlock the index
raise #but still throw an exception


As I've found that sometimes there are errors that occur
during .commit() (more on that in a forthcoming e-mail). This way
releases the lock so that it doesn't require manual deletion later
(and the associated risk of accidentally manually deleting the lock
when there actually is a process writing to it).

I was also wondering if you'd considered raising a custom exception
rather than the rather generic OSError to indicate that the index is
locked, which would make wrapping code cleaner (we could catch say a
LockError, rather than catching all OSErrors, and checking that
the .errno is equal to the error code of 17 for a file already
existing).

i.e In my working copy, I have the following lock() method:

def lock(self, name):
try:
os.mkdir(self._fpath(name))
except OSError, e:
if e.errno == errno.EEXIST:
raise LockError("Could not lock %s as file %s exists" %
(name, self._fpath(name)))
else:
raise
return True

This would make things clearer for users of the library such as Sandra.

(I can provide nice patched for both of these if you want Matt)

Any thoughts on either of these Matt?

Andy


Matt Chaput

unread,
Jul 13, 2009, 9:59:19 AM7/13/09
to who...@googlegroups.com
Andrew MacKinlay wrote:
> On the subject of that, have you considered updating the
> ContextManager code in writing.py to clean up after itself more
> thoroughly if exceptions occur during commit? i.e.

> I was also wondering if you'd considered raising a custom exception

> rather than the rather generic OSError to indicate that the index is
> locked, which would make wrapping code cleaner (we could catch say a
> LockError, rather than catching all OSErrors, and checking that
> the .errno is equal to the error code of 17 for a file already
> existing).

These are both excellent ideas. I'll work on getting them into the next
release.

Thanks, Andy!

Matt

Andrew MacKinlay

unread,
Jul 13, 2009, 10:28:39 AM7/13/09
to who...@googlegroups.com

On 13/07/2009, at 11:59 PM, Matt Chaput wrote:

> These are both excellent ideas. I'll work on getting them into the
> next
> release.
>

Great, thanks for that.

While we're there, is there any chance of getting the 2-line change I
posted at http://trac.whoosh.ca/ticket/46 into the next release as well?

Thanks,
Andy.

Matt Chaput

unread,
Jul 13, 2009, 10:58:51 AM7/13/09
to who...@googlegroups.com
> While we're there, is there any chance of getting the 2-line change I
> posted at http://trac.whoosh.ca/ticket/46 into the next release as well?

Yes, sorry about that :)

I've been tied up with other things and with working on a project to
change the posting format that hasn't been going well. Now I've got some
momentum with docs and performance improvements that are pretty
exciting, so I'll try to get back into the groove with releasing updates.

Matt

Reply all
Reply to author
Forward
0 new messages