Nico, On 18 Apr 2007, at 11:33, Nico de Jager wrote:

When one deletes an object with tx-delete-object after creating an index on a slot (other than id) of a managed prevalence class, the corresponding index entry is not deleted. Because adding a new object with tx-create-object appears to update all the indexes on the class, one would expect tx-delete-object to also update the indexes accordingly. Is this a bug or the intended behaviour?

The 'indexes on arbitrary slots' was contributed at one point. I do think the implementation was quite clear and simple. But you are right, this is a bug (or oversight): when deleting an object, the index entries should be cleaned up.

Also, shouldn't tx-create-object (or tx-change-object-slots) signal a condition when the addition of an object or the change of a slot results in duplicate slot values for an indexed slot?

Apart from indexes on keys (like ID), which are necessarily unique, indexes on arbitrary slots could theoretically be unique or not (as in SQL). The current implementation is using hashtables and is overwriting entries: so there too, there is a bug (or oversight): either we should enforce unique indexes by signalling errors, or we should allow multiple objects with the same indexed slot value, but then there should be a list as value there (and we have to manage all that correctly, esp. wrt. deleting objects). What to you think ? How are you using this feature ? So, thanks for reporting this problem. Do you feel like trying to fix this with a patch ? Are there any other people on the list who would like to comment ? Sven