April 2007 - cl-prevalence-devel@common-lisp.net

[cl-prevalence-devel] simple-array serialization patch
by Michael J. Forster 19 Apr '07

19 Apr '07

Hi Sven, I don't know if you or anyone else is interested, but I have implemented xml and sexp serialization/deserialization of simple arrays -- I needed it for an app that uses cl-prevalence. I've attached the patch. BTW, I would like to say that cl-prevalence is fantastic. We've been using it for five non-trivial (>25 classes, avg. 3000 instances per class) webapps without a hitch for almost a year now. Regards, Mike -- Michael J. Forster <mike(a)sharedlogic.ca>

2 3

Re: [cl-prevalence-devel] Removal of managed prevalence object does not delete corresponding non-id indexes' entries and duplicate index values allowed
by Nico de Jager 18 Apr '07

18 Apr '07

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

1 0

[cl-prevalence-devel] Removal of managed prevalence object does not delete corresponding non-id indexes' entries and duplicate index values allowed
by Nico de Jager 18 Apr '07

18 Apr '07

Hi 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? 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? Thanks. Nico

2 1

[cl-prevalence-devel] cl-prevalence speed issues
by Gabor Vitez 04 Apr '07

04 Apr '07

Hi, I just started to toy around with cl-prevalence; however I found strange speed issues: loading a database from transaction log is way faster than loading it from snapshot. I modified one of the test scripts from the cl-prevalence distribution: (require 'asdf) (require 'cl-prevalence) (in-package :cl-prevalence) (defclass numbers () ((numbers-list :accessor get-numbers-list :initform nil)) (:documentation "Object to hold our list of numbers")) (defun tx-create-numbers-root (system) "Transaction function to create a numbers instance as a root object" (setf (get-root-object system :numbers) (make-instance 'numbers))) (defun tx-add-number (system number) "Transaction function to add a number to the numbers list" (let ((numbers (get-root-object system :numbers))) (push number (get-numbers-list numbers)))) (defparameter *system-location* (pathname "/tmp/demo1-prevalence-system/") "Filesystem location of the prevalence system") (defvar *system* (time (make-prevalence-system *system-location*)) ) (execute *system* (make-transaction 'tx-create-numbers-root)) (time (dotimes (i 100000) (execute *system* (make-transaction 'tx-add-number i))) ) ;(time (snapshot *system*)) (close-open-streams *system*) I use this script to create a database; later to load it; then to snapshot it and load it again (uncommenting the appropriate parts between the runs). Creating and snapshotting is fast; however loading from snapshot is slow. Times: creating: 19.89 seconds loading from transaction log: 53.942 seconds < this is good snapshotting: 5.297 seconds loading from snapshot: 182.713 seconds < this is strange snapshotting again: 1.165 seconds Any ideas what this strangeness can be? Gabor

2 1