IE> Unfortunately aref is not a generic function so you'd have to play
IE> package naming games to hijack it which I abhor. I'm open to
IE> suggestions on ways to handle such an idiom, but nothing has come to
IE> mind yet. A macro to create slot accessors that do all the
IE> bookkeeping automatically might be useful as an option for users.
i'm not sure what do you mean by this macro (maybe you mean the same
thing?), but i think there is a way to track modifications:
object should track all the stuff that was read via slot-value, caching it,
and write all this stuff during commit.
i.e. on "user level" we can emulate it in such way:
(defparameter *slots-touched* ())
(defun cached-slot-value (o s)
(let ((k (cons o s)))
(multiple-value-bind (value found)
(gethash k *slots-touched*)
(if found
value
(setf (gethash k *slots-touched*) value)))))
;; setf cached-slot-value should be also implemented
(defun commit-cached-slots ()
(loop for (o . s) being each hash-key of *slots-touched*
using (hash-value value)
do (setf (slot-value o s) value)))
(ele:with-transaction ()
(let ((*slots-touched* (make-hash-table :test 'equalp)))
(setf (aref (cached-slot-value obj 'array) 5) 3)
(commit-cached-slots)))
this won't work with changes done outside a transaction, but I think that's
OK: use explicit transactions or die!
also, this could be a huge performance impact, but i think it can be
mitigated via hashing: i.e. in cached-slot-value we snapshot a sxhash of the
value.
during commit we check if sxhash was changed -- if it was, we write new slot
value into a database, otherwise we don't. we can also skip all immutable
values.
with this checks, performance impact should be barely noticable (comparing
to deseralization costs), so it should be OK.
_______________________________________________
elephant-devel site list
elephant-devel@common-lisp.net
http://common-lisp.net/mailman/listinfo/elephant-devel
