> Yes, I believe the Wiki has an example like this (a uniqueKey field > not named "id") Right, I should have looked there, too.
> > But after a <commit/> I found the number of documents unchanged > > in the stats. > What stat? maxDoc may be unchanged since it doesn't reflect deleted > documents that haven't been squeezed out of the index (it's a lucene > thing). numDocs should reflect the deletion. Yep, but numDocs is unchanged after a commit. I tried it again this morning step by step. Starting with a newly created index, the stats say numDocs : 9882062 maxDoc : 9882062 commits : 0 optimizes : 0 docsPending : 0 deletesPending : 0 adds : 0 deletesById : 0 deletesByQuery : 0 errors : 0 cumulative_adds : 0 cumulative_deletesById : 0 cumulative_deletesByQuery : 0 cumulative_errors : 0 docsDeleted : 0 After giving the delete-command this changed to numDocs : 9882062 maxDoc : 9882062 commits : 0 optimizes : 0 docsPending : 0 deletesPending : 1 adds : 0 deletesById : 1 deletesByQuery : 0 errors : 0 cumulative_adds : 0 cumulative_deletesById : 1 cumulative_deletesByQuery : 0 cumulative_errors : 0 docsDeleted : 0 And yes, I am absolutely sure the id I used for deletion existed in the index. I tried it later with a delete by query and it worked. (I just mention this because I found out that the stats look like that regardless of which id you use, an existing or non-existing one.) Finally after a commit I got: numDocs : 9882062 maxDoc : 9882062 commits : 1 optimizes : 0 docsPending : 0 deletesPending : 0 adds : 0 deletesById : 0 deletesByQuery : 0 errors : 0 cumulative_adds : 0 cumulative_deletesById : 1 cumulative_deletesByQuery : 0 cumulative_errors : 0 docsDeleted : 0 Apparently no change in the number of documents (and the document can still be found in the index). Could it be the problem is that my unique key field is of type slong (as defined in the tutorial)? Thanks, Marcus -- GMX Produkte empfehlen und ganz einfach Geld verdienen! Satte Provisionen für GMX Partner: http://www.gmx.net/de/go/partner
