cl-prevalence-devel

Download

cl-prevalence-devel@lists.common-lisp.net

April 2008

1 participants
1 discussions

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

09 Apr '08

(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

1 0