On Wednesday 18 April 2007 13:45, Sven Van Caekenberghe wrote:

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 ?

It would be really nice if INDEX-ON had an optional UNIQUE parameter that allows one to choose between either a unique or non-unique index. I would use both types.

B.t.w. why is SLOTS an optional parameter in the definition of INDEX-ON? As it is the function would do nothing if SLOTS is not supplied:

(defun index-on (system class &optional slots (test 'equalp)) "Create indexes on each of the slots provided." (dolist (slot slots) (execute-transaction (tx-create-objects-slot-index system class slot test))))

So, thanks for reporting this problem. Do you feel like trying to fix this with a patch ?

I would give it a try as soon as I can find the time. I am not an expert Lisper yet, so it will probably take me longer. But it will definitely be worth it, I have replaced all my CLSQL databases with cl-prevalence.

Are there any other people on the list who would like to comment ?

Sven

Thanks for your quick feedback.

Nico