[cl-prevalence-devel] Removal of managed prevalence object does not delete corresponding non-id indexes' entries and duplicate index values allowed

[Evan Monroig]

(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