(sorry for breaking the thread, I don't know how to recover it from pipermail. Original thread is here [1])

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.

I was bitten by this too, and fixed it by writing my own version tx-delete-object2 which you can compare to the original tx-delete-object below.

(defun tx-delete-object (system class id) "Delete the object of class with id from the system" (let ((object (find-object-with-id system class id))) (if object (let ((root-name (get-objects-root-name class)) (index-name (get-objects-slot-index-name class 'id))) (setf (get-root-object system root-name) (delete object (get-root-object system root-name))) (remhash id (get-root-object system index-name))) (error "no object of class ~a with id ~d found in ~s" class id system))))

(defun tx-delete-object2 (system class id &optional (indexed-slots '(id))) "Delete the object of class with id from the system" (let ((object (find-object-with-id system class id))) (if object (let ((root-name (get-objects-root-name class))) (setf (get-root-object system root-name) (delete object (get-root-object system root-name))) (dolist (slot indexed-slots) (remove-object-from-slot-index system class slot object))) (error "no object of class ~a with id ~d found in ~s" class id system))))

tx-delete-object2 doesn't address the possibility of an index having the possibility of pointing to several objects for each value as mentioned below.

...

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 ?

I also have wanted something like this. Use cases include slots that may be common among objects, or joins. For example, we have two classes Company and Person; each person has a slot company-id, and we may like to have an index on this slot to retrieve all the persons that have a specific company-id. Basically, this is a join, and having it precomputed in the form of indexes would speed up searching a lot once the database grows beyond some size.

Evan

[1] http://common-lisp.net/pipermail/cl-prevalence-devel/2007-April/000038.html