From kingruedi at c-plusplus.de Sat Nov 11 17:26:43 2006 From: kingruedi at c-plusplus.de (=?ISO-8859-1?Q?R=FCdiger_Sonderfeld?=) Date: Sat, 11 Nov 2006 18:26:43 +0100 Subject: [rucksack-devel] How to use Indexing? Message-ID: <5C2CB6A0-4FB9-4BE2-9372-3A2A70C86BE2@c-plusplus.de> Hello, I need help understanding the Indexing in rucksack. Here is a small example Code (with-rucksack (r "/tmp/foosack/") (with-transaction () (defclass article () ((title :initarg :title :accessor title :index :case-insensitive-string-index)) (:metaclass persistent-class) (:index t)) (add-rucksack-root (make-instance 'article :title "demo") r))) Now I want to search for the object by using the value of title as the index. Is this possible with rucksack? btw. Is there any example code or code of projects already using rucksack available? Regards, R?diger From ch-rucksack at bobobeach.com Mon Nov 13 18:55:51 2006 From: ch-rucksack at bobobeach.com (Cyrus Harmon) Date: Mon, 13 Nov 2006 10:55:51 -0800 Subject: [rucksack-devel] map-indexes flet -> labels Message-ID: <8913F71C-217C-468C-AB77-E7EED0CDF40D@bobobeach.com> Dear rucksack-devel, I'm new to rucksack, so forgive me if this is mistaken, but in rucksack.lisp, I think the map-indexes flet should be a labels instead of flet as it looks like map-indexes calls itself when include-subclasses is true. Thanks, Cyrus From ch-rucksack at bobobeach.com Tue Nov 14 23:24:36 2006 From: ch-rucksack at bobobeach.com (Cyrus Harmon) Date: Tue, 14 Nov 2006 15:24:36 -0800 Subject: [rucksack-devel] inherited slots Message-ID: <65D096E2-8B54-4D46-830A-2FED07FA1488@bobobeach.com> so when I set a class to have metaclass rucksack:persistent-class, the direct slots are persistent, but not the indirect (or inherited, whatever the proper term is) slots. Is this by design? e.g. if I do this: (defclass person () ((name :initform (elt *names* (random (length *names*))) :accessor name) (age :initform (random 100) :accessor age))) (defclass persistent-person (person) () (:metaclass persistent-class)) then persistent-person will not have persistent name and age slots, AFAICT. Thanks, Cyrus From alemmens at xs4all.nl Wed Nov 15 08:12:08 2006 From: alemmens at xs4all.nl (Arthur Lemmens) Date: Wed, 15 Nov 2006 09:12:08 +0100 Subject: [rucksack-devel] map-indexes flet -> labels In-Reply-To: <8913F71C-217C-468C-AB77-E7EED0CDF40D@bobobeach.com> References: <8913F71C-217C-468C-AB77-E7EED0CDF40D@bobobeach.com> Message-ID: Cyrus Harmon wrote: > in rucksack.lisp, I think the map-indexes flet should be a labels > instead of flet as it looks like map-indexes calls itself when > include-subclasses is true. Yes, I think you're right. Thanks, I'll fix this soon. Arthur From alemmens at xs4all.nl Wed Nov 15 08:15:14 2006 From: alemmens at xs4all.nl (Arthur Lemmens) Date: Wed, 15 Nov 2006 09:15:14 +0100 Subject: [rucksack-devel] inherited slots In-Reply-To: <65D096E2-8B54-4D46-830A-2FED07FA1488@bobobeach.com> References: <65D096E2-8B54-4D46-830A-2FED07FA1488@bobobeach.com> Message-ID: Cyrus Harmon wrote: > so when I set a class to have metaclass rucksack:persistent-class, > the direct slots are persistent, but not the indirect (or inherited, > whatever the proper term is) slots. Is this by design? No. See e.g. test-index-1a.lisp for a counter-example. > e.g. if I do this: > > (defclass person () > ((name :initform (elt *names* (random (length *names*))) > :accessor name) > (age :initform (random 100) :accessor age))) > > (defclass persistent-person (person) > () > (:metaclass persistent-class)) > > then persistent-person will not have persistent name and age slots, I haven't tested this, but I think it would be wise to add the (:METACLASS PERSISTENT-CLASS) option to the PERSON class too. Arthur From ch-rucksack at bobobeach.com Wed Nov 15 08:24:59 2006 From: ch-rucksack at bobobeach.com (Cyrus Harmon) Date: Wed, 15 Nov 2006 00:24:59 -0800 Subject: [rucksack-devel] inherited slots In-Reply-To: References: <65D096E2-8B54-4D46-830A-2FED07FA1488@bobobeach.com> Message-ID: On Nov 15, 2006, at 12:15 AM, Arthur Lemmens wrote: > Cyrus Harmon wrote: > >> so when I set a class to have metaclass rucksack:persistent-class, >> the direct slots are persistent, but not the indirect (or inherited, >> whatever the proper term is) slots. Is this by design? > > No. See e.g. test-index-1a.lisp for a counter-example. Ok, so in that case inherited slots from other :metaclass persistent- class classes are persistent. At least at first glance, it seems like it would be nice to use rucksack to make persistent versions of existing classes. See below... >> e.g. if I do this: >> >> (defclass person () >> ((name :initform (elt *names* (random (length *names*))) >> :accessor name) >> (age :initform (random 100) :accessor age))) >> >> (defclass persistent-person (person) >> () >> (:metaclass persistent-class)) >> >> then persistent-person will not have persistent name and age slots, > > I haven't tested this, but I think it would be wise to add the > (:METACLASS PERSISTENT-CLASS) option to the PERSON class too. Sure, that would work, but I'm imagining the case where person comes from some other library, and I want to make a persistent version of it. As it stands now, I have to redefine the slots in persistent- person to make them persistent. Why not make all slots persistent instead of only the slots that are defined in a class whose metaclass is persistent-class? I'm sure there are good reasons for the existing behavior, but my naive attempt to use rucksack started with attempting to make persistent versions of existing classes by subclassing them. Changing the existing classes themselves to be persistent seems a bit counterintuitive. Thanks, Cyrus From alemmens at xs4all.nl Wed Nov 15 08:31:32 2006 From: alemmens at xs4all.nl (Arthur Lemmens) Date: Wed, 15 Nov 2006 09:31:32 +0100 Subject: [rucksack-devel] inherited slots In-Reply-To: References: <65D096E2-8B54-4D46-830A-2FED07FA1488@bobobeach.com> Message-ID: Cyrus Harmon wrote: > Ok, so in that case inherited slots from other :metaclass persistent- > class classes are persistent. Yes. > Sure, that would work, but I'm imagining the case where person comes > from some other library, and I want to make a persistent version of > it. As it stands now, I have to redefine the slots in persistent- > person to make them persistent. Why not make all slots persistent > instead of only the slots that are defined in a class whose metaclass > is persistent-class? I think there may be some technical reasons (related to the MOP), but I'm not sure. I'll look into this, because I agree with you that this is something that you may want to do in practice. Arthur From ch-rucksack at bobobeach.com Wed Nov 15 08:34:48 2006 From: ch-rucksack at bobobeach.com (Cyrus Harmon) Date: Wed, 15 Nov 2006 00:34:48 -0800 Subject: [rucksack-devel] inherited slots In-Reply-To: References: <65D096E2-8B54-4D46-830A-2FED07FA1488@bobobeach.com> Message-ID: <2BDB80F6-A791-47ED-9A82-EEADE1242F04@bobobeach.com> On Nov 15, 2006, at 12:30 AM, Arthur Lemmens wrote: >> Sure, that would work, but I'm imagining the case where person comes >> from some other library, and I want to make a persistent version of >> it. As it stands now, I have to redefine the slots in persistent- >> person to make them persistent. Why not make all slots persistent >> instead of only the slots that are defined in a class whose metaclass >> is persistent-class? > > I think there may be some technical reasons (related to the MOP), but > I'm not sure. I'll look into this, because I agree with you that this > is something that you may want to do in practice. Thanks for looking into this. To be fair, I'm not sure that this is the _right_ thing to do, but rather it's what I expected to happen when I first tried playing around with the code. I think the existing behavior is reasonable too, although my naive preference would be for all slots to be persistent. If there are MOP-ish reasons for this not to be the case, so be it. But, again, at first glance, it seems like it would be nice to somewhat trivially make persistent versions of existing classes. Thanks again, Cyrus From alemmens at xs4all.nl Thu Nov 16 08:04:27 2006 From: alemmens at xs4all.nl (Arthur Lemmens) Date: Thu, 16 Nov 2006 09:04:27 +0100 Subject: [rucksack-devel] How to use Indexing? In-Reply-To: <5C2CB6A0-4FB9-4BE2-9372-3A2A70C86BE2@c-plusplus.de> References: <5C2CB6A0-4FB9-4BE2-9372-3A2A70C86BE2@c-plusplus.de> Message-ID: [Sorry for the late reply.] R?diger Sonderfeld wrote: > (with-rucksack (r "/tmp/foosack/") > (with-transaction () > (defclass article () > ((title :initarg :title :accessor title > :index :case-insensitive-string-index)) > (:metaclass persistent-class) > (:index t)) > (add-rucksack-root (make-instance 'article :title "demo") r))) > > Now I want to search for the object by using the value of title as > the index. Is this possible with rucksack? Yes, definitely. At the moment there is no special search function, but it's easy to define one on top of RUCKSACK-MAP-SLOT. You should probably use the :EQUAL keyword argument in this case. See the examples in test-index*.lisp and the documentation strings for RUCKSACK-MAP-SLOT and MAP-INDEX. Let me know if you need more help. > btw. Is there any example code or code of projects already using > rucksack available? I'm not using Rucksack for my own projects at the moment (too busy consulting), and I'm aware of at least one bug that needs to be fixed before I would trust it for real work. You can see the bug by running BTREE-STRESS-TEST; sooner or later it will fail with an inconsistent btree. I think this means that there's a (very rarely occurring) problem in BTREE-DELETE. Arthur From ch-rucksack at bobobeach.com Tue Nov 28 19:42:30 2006 From: ch-rucksack at bobobeach.com (Cyrus Harmon) Date: Tue, 28 Nov 2006 11:42:30 -0800 Subject: [rucksack-devel] inherited slots In-Reply-To: <2BDB80F6-A791-47ED-9A82-EEADE1242F04@bobobeach.com> References: <65D096E2-8B54-4D46-830A-2FED07FA1488@bobobeach.com> <2BDB80F6-A791-47ED-9A82-EEADE1242F04@bobobeach.com> Message-ID: <53041A9E-E48A-46ED-B334-15FA8EF0B6F7@bobobeach.com> Hi Arthur, I just wanted to follow up any on this. Any further ideas as to whether or not this is 1) a good idea and 2) possible? Thanks, Cyrus On Nov 15, 2006, at 12:34 AM, Cyrus Harmon wrote: > > On Nov 15, 2006, at 12:30 AM, Arthur Lemmens wrote: > >>> Sure, that would work, but I'm imagining the case where person comes >>> from some other library, and I want to make a persistent version of >>> it. As it stands now, I have to redefine the slots in persistent- >>> person to make them persistent. Why not make all slots persistent >>> instead of only the slots that are defined in a class whose >>> metaclass >>> is persistent-class? >> >> I think there may be some technical reasons (related to the MOP), but >> I'm not sure. I'll look into this, because I agree with you that >> this >> is something that you may want to do in practice. > > Thanks for looking into this. To be fair, I'm not sure that this is > the _right_ thing to do, but rather it's what I expected to happen > when I first tried playing around with the code. I think the > existing behavior is reasonable too, although my naive preference > would be for all slots to be persistent. If there are MOP-ish > reasons for this not to be the case, so be it. But, again, at first > glance, it seems like it would be nice to somewhat trivially make > persistent versions of existing classes. > > Thanks again, > > Cyrus > > _______________________________________________ > rucksack-devel mailing list > rucksack-devel at common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/rucksack-devel From nikodemus at random-state.net Wed Nov 29 07:43:28 2006 From: nikodemus at random-state.net (Nikodemus Siivola) Date: Wed, 29 Nov 2006 09:43:28 +0200 Subject: [rucksack-devel] inherited slots In-Reply-To: <53041A9E-E48A-46ED-B334-15FA8EF0B6F7@bobobeach.com> (Cyrus Harmon's message of "Tue, 28 Nov 2006 11:42:30 -0800") References: <65D096E2-8B54-4D46-830A-2FED07FA1488@bobobeach.com> <2BDB80F6-A791-47ED-9A82-EEADE1242F04@bobobeach.com> <53041A9E-E48A-46ED-B334-15FA8EF0B6F7@bobobeach.com> Message-ID: <87slg2u28v.fsf@logxor.random-state.net> Cyrus Harmon writes: > I just wanted to follow up any on this. Any further ideas as to > whether or not this is 1) a good idea and 2) possible? I'm not Arthur, but I thought there was a reason why doing that for inherited slots was nasty. Not that I can put my finger on it right now, so call it intuition. > Thanks, > > Cyrus > > On Nov 15, 2006, at 12:34 AM, Cyrus Harmon wrote: > >> >> On Nov 15, 2006, at 12:30 AM, Arthur Lemmens wrote: >> >>>> Sure, that would work, but I'm imagining the case where person comes >>>> from some other library, and I want to make a persistent version of >>>> it. As it stands now, I have to redefine the slots in persistent- >>>> person to make them persistent. Why not make all slots persistent >>>> instead of only the slots that are defined in a class whose >>>> metaclass >>>> is persistent-class? >>> >>> I think there may be some technical reasons (related to the MOP), but >>> I'm not sure. I'll look into this, because I agree with you that >>> this >>> is something that you may want to do in practice. >> >> Thanks for looking into this. To be fair, I'm not sure that this is >> the _right_ thing to do, but rather it's what I expected to happen >> when I first tried playing around with the code. I think the >> existing behavior is reasonable too, although my naive preference >> would be for all slots to be persistent. If there are MOP-ish >> reasons for this not to be the case, so be it. But, again, at first >> glance, it seems like it would be nice to somewhat trivially make >> persistent versions of existing classes. >> >> Thanks again, >> >> Cyrus >> >> _______________________________________________ >> rucksack-devel mailing list >> rucksack-devel at common-lisp.net >> http://common-lisp.net/cgi-bin/mailman/listinfo/rucksack-devel > > _______________________________________________ > rucksack-devel mailing list > rucksack-devel at common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/rucksack-devel -- Cheers, -- Nikodemus Schemer: "Buddha is small, clean, and serious." Lispnik: "Buddha is big, has hairy armpits, and laughs." From ch-rucksack at bobobeach.com Wed Nov 29 07:55:06 2006 From: ch-rucksack at bobobeach.com (Cyrus Harmon) Date: Tue, 28 Nov 2006 23:55:06 -0800 Subject: [rucksack-devel] inherited slots In-Reply-To: <87slg2u28v.fsf@logxor.random-state.net> References: <65D096E2-8B54-4D46-830A-2FED07FA1488@bobobeach.com> <2BDB80F6-A791-47ED-9A82-EEADE1242F04@bobobeach.com> <53041A9E-E48A-46ED-B334-15FA8EF0B6F7@bobobeach.com> <87slg2u28v.fsf@logxor.random-state.net> Message-ID: <3E6CF627-18A9-4210-B88C-8E0F53D73AA6@bobobeach.com> On Nov 28, 2006, at 11:43 PM, Nikodemus Siivola wrote: > Cyrus Harmon writes: > >> I just wanted to follow up any on this. Any further ideas as to >> whether or not this is 1) a good idea and 2) possible? > > I'm not Arthur, but I thought there was a reason why doing that > for inherited slots was nasty. Not that I can put my finger on it > right now, so call it intuition. Hmm... okay. The obvious motivation for this is that one could subclass an existing class with a rucksack metaclass and get a persistent version of existing data. I can see how this might give folks the heebie-jeebies, but it would be nice to better understand what's _wrong_ with this approach. As an alternative, perhaps a defclass option for inherited slots that _should_ be persistent would be nice, as opposed to having redefine every slot that should be persistent. Cyrus From ch-rucksack at bobobeach.com Wed Nov 29 08:06:39 2006 From: ch-rucksack at bobobeach.com (Cyrus Harmon) Date: Wed, 29 Nov 2006 00:06:39 -0800 Subject: [rucksack-devel] inherited slots In-Reply-To: <3E6CF627-18A9-4210-B88C-8E0F53D73AA6@bobobeach.com> References: <65D096E2-8B54-4D46-830A-2FED07FA1488@bobobeach.com> <2BDB80F6-A791-47ED-9A82-EEADE1242F04@bobobeach.com> <53041A9E-E48A-46ED-B334-15FA8EF0B6F7@bobobeach.com> <87slg2u28v.fsf@logxor.random-state.net> <3E6CF627-18A9-4210-B88C-8E0F53D73AA6@bobobeach.com> Message-ID: <28CDCF55-100D-426A-9229-D0137965256F@bobobeach.com> On Nov 28, 2006, at 11:55 PM, Cyrus Harmon wrote: > > On Nov 28, 2006, at 11:43 PM, Nikodemus Siivola wrote: >> Cyrus Harmon writes: >> >>> I just wanted to follow up any on this. Any further ideas as to >>> whether or not this is 1) a good idea and 2) possible? >> >> I'm not Arthur, but I thought there was a reason why doing that >> for inherited slots was nasty. Not that I can put my finger on it >> right now, so call it intuition. > > Hmm... okay. The obvious motivation for this is that one could > subclass an existing class with a rucksack metaclass and get a > persistent version of existing data. I can see how this might give > folks the heebie-jeebies, but it would be nice to better understand > what's _wrong_ with this approach. As an alternative, perhaps a > defclass option for inherited slots that _should_ be persistent > would be nice, as opposed to having redefine every slot that should > be persistent. You know, like maybe a :persistent-slots option to the class definition. Oh, what's that you say, that's already there? Great, I'll try that. Thanks! Cyrus From ch-rucksack at bobobeach.com Wed Nov 29 18:56:25 2006 From: ch-rucksack at bobobeach.com (Cyrus Harmon) Date: Wed, 29 Nov 2006 10:56:25 -0800 Subject: [rucksack-devel] inherited slots In-Reply-To: <28CDCF55-100D-426A-9229-D0137965256F@bobobeach.com> References: <65D096E2-8B54-4D46-830A-2FED07FA1488@bobobeach.com> <2BDB80F6-A791-47ED-9A82-EEADE1242F04@bobobeach.com> <53041A9E-E48A-46ED-B334-15FA8EF0B6F7@bobobeach.com> <87slg2u28v.fsf@logxor.random-state.net> <3E6CF627-18A9-4210-B88C-8E0F53D73AA6@bobobeach.com> <28CDCF55-100D-426A-9229-D0137965256F@bobobeach.com> Message-ID: <6A8E8798-BB37-48B0-942F-8079F5AEDE69@bobobeach.com> On Nov 29, 2006, at 12:06 AM, Cyrus Harmon wrote: > On Nov 28, 2006, at 11:55 PM, Cyrus Harmon wrote: >> Hmm... okay. The obvious motivation for this is that one could >> subclass an existing class with a rucksack metaclass and get a >> persistent version of existing data. I can see how this might give >> folks the heebie-jeebies, but it would be nice to better >> understand what's _wrong_ with this approach. As an alternative, >> perhaps a defclass option for inherited slots that _should_ be >> persistent would be nice, as opposed to having redefine every slot >> that should be persistent. > > You know, like maybe a :persistent-slots option to the class > definition. Oh, what's that you say, that's already there? Great, > I'll try that. Thanks! Ok, obviously that was wrong... So I guess the questions are: 1) How can I make inherited slots (from non-persistent classes) persistent? It seems that the answer is that I can just list them in the slot definitions for the persistent class and that they will pick up the appropriate slot definition arguments, or whatever they are called (:initarg, :initform, etc...) from the parent class. 2) What happens to non-persistent slots (in this case of parent classes) when an object is serialized form disk? If I try the following (adapted from the rucksack-test file): (cl:defpackage :rucksack-object-test (:use :cl :rucksack)) (cl:in-package :rucksack-object-test) (defparameter *test-suite* #p"/tmp/rucksack-object-test/") (defparameter *names* '("David" "Jim" "Peter" "Thomas" "Arthur" "Jans" "Klaus" "James" "Martin")) (defclass thingy () ((frobosity :accessor frobosity :initarg :frobosity :initform 32))) (defclass person (thingy) ((name :initform (elt *names* (random (length *names*))) :accessor name) (age :initform (random 100) :accessor age)) (:metaclass persistent-class)) (defmethod print-object ((person person) stream) (print-unreadable-object (person stream :type t) (format stream "called ~S of age ~D" (name person) (age person)))) (defun test-create (&key (nr-objects 2)) "Test creating a rucksack with many persons." (with-rucksack (rucksack *test-suite* :if-exists :supersede) (with-transaction () (loop for i below nr-objects do (let ((person (make-instance 'person))) (add-rucksack-root person rucksack)))))) (defun test-get () (with-rucksack (rucksack *test-suite*) (with-transaction () (map-rucksack-roots (lambda (root) (print (cons root (frobosity root)))) rucksack)))) If I call test-create and then test-get, I get unbound-slot errors for frobosity. I guess this makes sense, but I would have expected 32 as the answer. Thanks, Cyrus From ch-rucksack at bobobeach.com Wed Nov 29 23:54:25 2006 From: ch-rucksack at bobobeach.com (Cyrus Harmon) Date: Wed, 29 Nov 2006 15:54:25 -0800 Subject: [rucksack-devel] indexing issue? Message-ID: <42002F55-6253-465C-BC6F-33CE9A84DA80@bobobeach.com> perhaps I'm doing something wrong here, but I can't seem to get indexing for non symbols to work properly: ===== (cl:defpackage :rucksack-object-test (:use :cl :rucksack)) (cl:in-package :rucksack-object-test) (eval-when (:compile-toplevel :load-toplevel) (defparameter *test-suite* #p"/tmp/rucksack-object-test/")) (defparameter *names* '("David" "Jim" "Peter" "Thomas" "Arthur" "Jans" "Klaus" "James" "Martin")) (defparameter *moods* '("Happy" "Sad" "Mad" "Tired" "Bored")) (defclass thingy () ((frobosity :accessor frobosity :initarg :frobosity :initform 32))) (eval-when (:compile-toplevel :load-toplevel) (with-rucksack (rucksack *test-suite* :if-exists :supersede) (with-transaction () (defclass person (thingy) ((id :initform (gensym "PERSON-") :reader hacker-id :index :symbol-index :unique t) (name :initform (elt *names* (random (length *names*))) :initarg :name :accessor name :index :case-insensitive-string-index) (age :initform (random 100) :initarg :age :accessor age :index :number-index) (mood :initform (elt *moods* (random (length *moods*))) :accessor mood :index :string-index)) (:metaclass persistent-class) (:index t))))) (defmethod print-object ((person person) stream) (print-unreadable-object (person stream :type t) (format stream "called ~S of age ~D who is ~A" (name person) (age person) (mood person)))) (defun test-create (&key (nr-objects 10)) "Test creating a rucksack with many persons." (with-rucksack (rucksack *test-suite*) (with-transaction () (loop for i below nr-objects do (let ((person (make-instance 'person :age i))) (print (age person)) (add-rucksack-root person rucksack)))))) (defun test-get () (with-rucksack (rucksack *test-suite*) (with-transaction () (map-rucksack-roots (lambda (root) (print (cons root (frobosity root)))) rucksack)))) (defun test-number-index () (with-rucksack (rucksack *test-suite*) (with-transaction () (rucksack-map-slot rucksack 'person 'age #'print :equal 1)))) (defun test-string-index () (with-rucksack (rucksack *test-suite*) (with-transaction () (rucksack-map-slot rucksack 'person 'mood #'print :equal "Sad"))) (with-rucksack (rucksack *test-suite*) (with-transaction () (dotimes (i 10) (let ((q (make-instance 'person))) (add-rucksack-root q rucksack)))))) ====== and then (test-create) (test-number-index) gives the following: Argument X is not a NUMBER: #> [Condition of type SIMPLE-TYPE-ERROR] Restarts: 0: [ABORT] Abort # 1: [RETRY] Retry # 2: [ABORT-REQUEST] Abort handling SLIME request. 3: [TERMINATE-THREAD] Terminate this thread (#) Backtrace: 0: (SB-KERNEL:TWO-ARG-* #> 16) 1: (RUCKSACK::OBJECT-ID-TO-BLOCK #> #) 2: (RUCKSACK::OBJECT-HEAP-POSITION # #>) 3: (RUCKSACK::FIND-COMMITTED-OBJECT-VERSION #> 337383312100000 #) 4: ((SB-PCL::FAST-METHOD RUCKSACK::LOAD-OBJECT (T T STANDARD- CACHE)) # # #> # #) 5: ((SB-PCL::FAST-METHOD CACHE-GET-OBJECT (T STANDARD-CACHE)) # # #> #) 6: ((LAMBDA (SLOT-VALUE OBJECT-ID)) # #>) 7: ((LABELS RUCKSACK::MAP-SLOT) #) 8: ((SB-PCL::FAST-METHOD RUCKSACK-MAP-SLOT (STANDARD-RUCKSACK #1="#<...>" . #1#)) # # # PERSON AGE #) 9: (TEST-NUMBER-INDEX) 10: (SB-INT:SIMPLE-EVAL-IN-LEXENV (TEST-NUMBER-INDEX) #) --more-- any ideas what I might be doing wrong? Thanks, Cyrus From ch-rucksack at bobobeach.com Thu Nov 30 00:32:12 2006 From: ch-rucksack at bobobeach.com (Cyrus Harmon) Date: Wed, 29 Nov 2006 16:32:12 -0800 Subject: [rucksack-devel] indexing issue? In-Reply-To: <42002F55-6253-465C-BC6F-33CE9A84DA80@bobobeach.com> References: <42002F55-6253-465C-BC6F-33CE9A84DA80@bobobeach.com> Message-ID: Ah, it's not the symbol that's the issue, it's that I can't do rucksack-map-slot unless :unique is t. I assume this should work for non-unique indices as well? Thanks, Cyrus On Nov 29, 2006, at 3:54 PM, Cyrus Harmon wrote: > perhaps I'm doing something wrong here, but I can't seem to get > indexing for non symbols to work properly: > > ===== > > (cl:defpackage :rucksack-object-test (:use :cl :rucksack)) > > (cl:in-package :rucksack-object-test) > > (eval-when (:compile-toplevel :load-toplevel) > (defparameter *test-suite* #p"/tmp/rucksack-object-test/")) > > (defparameter *names* '("David" "Jim" "Peter" "Thomas" > "Arthur" "Jans" "Klaus" "James" "Martin")) > > (defparameter *moods* '("Happy" "Sad" "Mad" "Tired" "Bored")) > > (defclass thingy () > ((frobosity :accessor frobosity :initarg :frobosity :initform 32))) > > (eval-when (:compile-toplevel :load-toplevel) > (with-rucksack (rucksack *test-suite* :if-exists :supersede) > (with-transaction () > (defclass person (thingy) > ((id :initform (gensym "PERSON-") > :reader hacker-id > :index :symbol-index > :unique t) > (name :initform (elt *names* (random (length *names*))) > :initarg :name > :accessor name > :index :case-insensitive-string-index) > (age :initform (random 100) > :initarg :age > :accessor age > :index :number-index) > (mood :initform (elt *moods* (random (length *moods*))) > :accessor mood > :index :string-index)) > (:metaclass persistent-class) > (:index t))))) > > (defmethod print-object ((person person) stream) > (print-unreadable-object (person stream :type t) > (format stream "called ~S of age ~D who is ~A" > (name person) > (age person) > (mood person)))) > > (defun test-create (&key (nr-objects 10)) > "Test creating a rucksack with many persons." > (with-rucksack (rucksack *test-suite*) > (with-transaction () > (loop for i below nr-objects > do (let ((person (make-instance 'person :age i))) > (print (age person)) > (add-rucksack-root person rucksack)))))) > > (defun test-get () > (with-rucksack (rucksack *test-suite*) > (with-transaction () > (map-rucksack-roots (lambda (root) > (print (cons root (frobosity root)))) > rucksack)))) > > (defun test-number-index () > (with-rucksack (rucksack *test-suite*) > (with-transaction () > (rucksack-map-slot rucksack 'person 'age #'print :equal 1)))) > > (defun test-string-index () > (with-rucksack (rucksack *test-suite*) > (with-transaction () > (rucksack-map-slot rucksack 'person 'mood #'print :equal > "Sad"))) > > (with-rucksack (rucksack *test-suite*) > (with-transaction () > (dotimes (i 10) (let ((q (make-instance 'person))) > (add-rucksack-root q rucksack)))))) > > ====== > > and then > > (test-create) > (test-number-index) > > gives the following: > > Argument X is not a NUMBER: > # tmp/rucksack-object-test/heap" and 24 objects in memory.>> > [Condition of type SIMPLE-TYPE-ERROR] > > Restarts: > 0: [ABORT] Abort # dirty objects> > 1: [RETRY] Retry # dirty objects> > 2: [ABORT-REQUEST] Abort handling SLIME request. > 3: [TERMINATE-THREAD] Terminate this thread (# thread" {1190A6B1}>) > > Backtrace: > 0: (SB-KERNEL:TWO-ARG-* # of size 10000, heap #P"/tmp/rucksack-object-test/heap" and 24 > objects in memory.>> 16) > 1: (RUCKSACK::OBJECT-ID-TO-BLOCK # # heap" and 24 objects in memory.>> # {128C6A29}>) > 2: (RUCKSACK::OBJECT-HEAP-POSITION # {128C6A29}> # 10000, heap #P"/tmp/rucksack-object-test/heap" and 24 objects in > memory.>>) > 3: (RUCKSACK::FIND-COMMITTED-OBJECT-VERSION # in # test/heap" and 24 objects in memory.>> 337383312100000 # SWEEP-HEAP {128C8499}>) > 4: ((SB-PCL::FAST-METHOD RUCKSACK::LOAD-OBJECT (T T STANDARD- > CACHE)) # # > # tmp/rucksack-object-test/heap" and 24 objects in memory.>> > # > # heap" and 24 objects in memory.>) > 5: ((SB-PCL::FAST-METHOD CACHE-GET-OBJECT (T STANDARD-CACHE)) > # # # #97 in # test/heap" and 24 objects in memory.>> # 10000, heap #P"/tmp/rucksack-object-test/heap" and 24 objects in > memory.>) > 6: ((LAMBDA (SLOT-VALUE OBJECT-ID)) # > # tmp/rucksack-object-test/heap" and 24 objects in memory.>>) > 7: ((LABELS RUCKSACK::MAP-SLOT) #) > 8: ((SB-PCL::FAST-METHOD RUCKSACK-MAP-SLOT (STANDARD-RUCKSACK > #1="#<...>" . #1#)) # # > # test/" with 10 roots {128C3319}> PERSON AGE #) > 9: (TEST-NUMBER-INDEX) > 10: (SB-INT:SIMPLE-EVAL-IN-LEXENV (TEST-NUMBER-INDEX) #) > --more-- > > > any ideas what I might be doing wrong? > > Thanks, > > Cyrus > > _______________________________________________ > rucksack-devel mailing list > rucksack-devel at common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/rucksack-devel From alemmens at xs4all.nl Thu Nov 30 10:52:50 2006 From: alemmens at xs4all.nl (Arthur Lemmens) Date: Thu, 30 Nov 2006 11:52:50 +0100 Subject: [rucksack-devel] indexing issue? In-Reply-To: References: <42002F55-6253-465C-BC6F-33CE9A84DA80@bobobeach.com> Message-ID: Cyrus Harmon wrote: > Ah, it's not the symbol that's the issue, it's that I can't do > rucksack-map-slot unless :unique is t. I assume this should work for > non-unique indices as well? Yes, it should but it didn't ;-) The combination of an EQUAL parameter and non-unique keys wasn't handled correctly by MAP-INDEX-DATA. The bug fix is in CVS now (along with a fix for the FLET instead of LABELS bug that you reported two weeks ago). Thanks very much for the bug report. Arthur From alemmens at xs4all.nl Thu Nov 30 10:58:33 2006 From: alemmens at xs4all.nl (Arthur Lemmens) Date: Thu, 30 Nov 2006 11:58:33 +0100 Subject: [rucksack-devel] inherited slots In-Reply-To: <53041A9E-E48A-46ED-B334-15FA8EF0B6F7@bobobeach.com> References: <65D096E2-8B54-4D46-830A-2FED07FA1488@bobobeach.com> <2BDB80F6-A791-47ED-9A82-EEADE1242F04@bobobeach.com> <53041A9E-E48A-46ED-B334-15FA8EF0B6F7@bobobeach.com> Message-ID: Cyrus Harmon wrote: > I just wanted to follow up any on this. Any further ideas as to > whether or not this is 1) a good idea and 2) possible? Sorry, I haven't had time to look into this yet. I'll try to find an hour this weekend and come back to you. Arthur From ch-rucksack at bobobeach.com Thu Nov 30 17:50:13 2006 From: ch-rucksack at bobobeach.com (Cyrus Harmon) Date: Thu, 30 Nov 2006 09:50:13 -0800 Subject: [rucksack-devel] indexing issue? In-Reply-To: References: <42002F55-6253-465C-BC6F-33CE9A84DA80@bobobeach.com> Message-ID: <15FC081E-4C24-4CE6-8C5D-D6C3AE30AFA6@bobobeach.com> Thanks! This works now. But that leads to my next question... What is the intended behavior of a unique slot? I'm able to make-instance new instances of a persistent class with a duplicate slot value, which seems fine. I'm even able to add-rucksack-root these instances. When I try to rucksack-map-slot over the index with the uniqueness constraint, I get a subset of the objects, containing unique slots. When I map over the same data with a slot without a :unique constraint, I get all of the objects. It seems a bit odd that you get different results depending on the index. I would expect the index to provide an ordering and an efficient lookup method, but not to change the results. Should the add-rucksack-root be failing in this case or am I missing something about how this works? here's a test using my previous example: (defun test-unique-index () (with-rucksack (rucksack *test-suite*) (with-transaction () (rucksack-map-slot rucksack 'person 'beer #'print)))) (defun test-non-unique-index () (with-rucksack (rucksack *test-suite*) (with-transaction () (rucksack-map-slot rucksack 'person 'name #'print)))) RUCKSACK-OBJECT-TEST> (test-unique-index) # # # # RUCKSACK-OBJECT-TEST> (test-non-unique-index) # # # ... Thanks again! Cyrus On Nov 30, 2006, at 2:52 AM, Arthur Lemmens wrote: > Cyrus Harmon wrote: > >> Ah, it's not the symbol that's the issue, it's that I can't do >> rucksack-map-slot unless :unique is t. I assume this should work for >> non-unique indices as well? > > Yes, it should but it didn't ;-) > > The combination of an EQUAL parameter and non-unique keys wasn't > handled correctly by MAP-INDEX-DATA. The bug fix is in CVS now > (along with a fix for the FLET instead of LABELS bug that you > reported two weeks ago). > > Thanks very much for the bug report. > > Arthur > From alemmens at xs4all.nl Thu Nov 30 18:43:17 2006 From: alemmens at xs4all.nl (Arthur Lemmens) Date: Thu, 30 Nov 2006 19:43:17 +0100 Subject: [rucksack-devel] indexing issue? In-Reply-To: <15FC081E-4C24-4CE6-8C5D-D6C3AE30AFA6@bobobeach.com> References: <42002F55-6253-465C-BC6F-33CE9A84DA80@bobobeach.com> <15FC081E-4C24-4CE6-8C5D-D6C3AE30AFA6@bobobeach.com> Message-ID: Cyrus Harmon wrote: > What is the intended behavior of a unique slot? If a class has a unique slot, you (the programmer) promise that there won't be two instances of that class which have a 'similar' value for that slot. The definition of 'similar' depends on the kind of index you create (see the predefined index specs in index.lisp for some examples). > I'm able to make-instance new instances of a persistent class with > a duplicate slot value Yes, I think that Rucksack doesn't check for this at the moment. But it should have signalled an error, I think. > which seems fine I don't think so ;-) > I'm even able to add-rucksack-root these instances. All class and slot indexes are automatically added to the root set. So if you create an instance of a class that has an indexed slot, that instance will automatically be reachable from the roots and it won't be removed by Rucksack's garbage collector. So in this case it doesn't really matter that you called ADD-RUCKSACK-ROOT. > I try to rucksack-map-slot over the index with the uniqueness > constraint, I get a subset of the objects, containing unique slots. Yes. I'd guess that you get those objects that were created most recently. But that's just an accident: you're not supposed to create two instances of the same class with the same value for a unique slot. > Should the add-rucksack-root be failing in this case No, I think that the second MAKE-INSTANCE (where you try to 'create' the duplicate slot value) should fail already. I'll add a check for that as soon as I have time. (My guess is that this should be pretty easy, and you may want to try this yourself. Probably adding an :ERROR keyword argument to the right call to BTREE-INSERT will do the trick.) Arthur From ch-rucksack at bobobeach.com Thu Nov 30 18:51:59 2006 From: ch-rucksack at bobobeach.com (Cyrus Harmon) Date: Thu, 30 Nov 2006 10:51:59 -0800 Subject: [rucksack-devel] indexing issue? In-Reply-To: References: <42002F55-6253-465C-BC6F-33CE9A84DA80@bobobeach.com> <15FC081E-4C24-4CE6-8C5D-D6C3AE30AFA6@bobobeach.com> Message-ID: On Nov 30, 2006, at 10:43 AM, Arthur Lemmens wrote: > Cyrus Harmon wrote: > >> What is the intended behavior of a unique slot? > > If a class has a unique slot, you (the programmer) promise that there > won't be two instances of that class which have a 'similar' value > for that slot. The definition of 'similar' depends on the kind of > index you create (see the predefined index specs in index.lisp for > some examples). Ok, I'd feel better if the system were to promise me that it were not to allow such a scenario. I don't suppose there is any notion of a multi-slot index or a multi-slot uniqueness constraint? (my SQL background/bias is probably showing through here). Also, presumably this uniqueness constraint is per-rucksack, not globally for all instances of this class. I wonder how subclassing affects this... >> I'm able to make-instance new instances of a persistent class with >> a duplicate slot value > > Yes, I think that Rucksack doesn't check for this at the moment. > But it should have signalled an error, I think. > >> which seems fine > > I don't think so ;-) > >> I'm even able to add-rucksack-root these instances. > > All class and slot indexes are automatically added to the root set. > So if you create an instance of a class that has an indexed slot, > that instance will automatically be reachable from the roots and it > won't be removed by Rucksack's garbage collector. Hmm... Ok, this I still don't quite get. when I make-instance a persistent object, I should then be able to map-rucksack-roots to get this instance? >> Should the add-rucksack-root be failing in this case > > No, I think that the second MAKE-INSTANCE (where you try to 'create' > the duplicate slot value) should fail already. I'll add a check for > that as soon as I have time. sounds good. thanks. > (My guess is that this should be pretty easy, and you may want to try > this yourself. Probably adding an :ERROR keyword argument to the > right > call to BTREE-INSERT will do the trick.) I'll try to take a look. On a related note, how do I go about explicitly deleting objects? I notice that delete-rucksack-root is not exported. is this intentional? thanks, Cyrus From attila.lendvai at gmail.com Thu Nov 30 19:08:29 2006 From: attila.lendvai at gmail.com (Attila Lendvai) Date: Thu, 30 Nov 2006 20:08:29 +0100 Subject: [rucksack-devel] indexing issue? In-Reply-To: References: <42002F55-6253-465C-BC6F-33CE9A84DA80@bobobeach.com> <15FC081E-4C24-4CE6-8C5D-D6C3AE30AFA6@bobobeach.com> Message-ID: > (My guess is that this should be pretty easy, and you may want to try > this yourself. Probably adding an :ERROR keyword argument to the right > call to BTREE-INSERT will do the trick.) in such sutuations i usually add a :when-exists keyword arg with type (or function (member :error :warn ...)) and when a lambda is passed then (funcall it object). -- - attila "- The truth is that I've been too considerate, and so became unintentionally cruel... - I understand. - No, you don't understand! We don't speak the same language!" (Ingmar Bergman - Smultronst?llet) From alemmens at xs4all.nl Thu Nov 30 19:13:03 2006 From: alemmens at xs4all.nl (Arthur Lemmens) Date: Thu, 30 Nov 2006 20:13:03 +0100 Subject: [rucksack-devel] indexing issue? In-Reply-To: References: <42002F55-6253-465C-BC6F-33CE9A84DA80@bobobeach.com> <15FC081E-4C24-4CE6-8C5D-D6C3AE30AFA6@bobobeach.com> Message-ID: Attila Lendvai wrote: >> (My guess is that this should be pretty easy, and you may want to try >> this yourself. Probably adding an :ERROR keyword argument to the right >> call to BTREE-INSERT will do the trick.) > > in such sutuations i usually add a :when-exists keyword arg with type > (or function (member :error :warn ...)) and when a lambda is passed > then (funcall it object). Yeah, I did it slightly differently. Here's the doc string for BTREE-INSERT: (defgeneric btree-insert (btree key value &key if-exists) (:documentation "Adds an association from KEY to VALUE to a btree. IF-EXISTS can be either :OVERWRITE (default) or :ERROR. If the btree has unique keys (see BTREE-UNIQUE-KEYS-P) and KEY is already associated with another (according to BTREE-VALUE=) value, the result depends on the IF-EXISTS option: if IF-EXISTS is :OVERWRITE, the old value is overwriten; if IF-EXISTS is :ERROR, a BTREE-KEY-ALREADY-PRESENT-ERROR is signaled. For btrees with non-unique keys, the IF-EXISTS option is ignored and VALUE is just added to the list of values associated with KEY (unless VALUE is already associated with KEY; in that case nothing happens).")) Arthur From alemmens at xs4all.nl Thu Nov 30 19:21:08 2006 From: alemmens at xs4all.nl (Arthur Lemmens) Date: Thu, 30 Nov 2006 20:21:08 +0100 Subject: [rucksack-devel] indexing issue? In-Reply-To: References: <42002F55-6253-465C-BC6F-33CE9A84DA80@bobobeach.com> <15FC081E-4C24-4CE6-8C5D-D6C3AE30AFA6@bobobeach.com> Message-ID: Cyrus Harmon wrote: >> If a class has a unique slot, you (the programmer) promise that there >> won't be two instances of that class which have a 'similar' value >> for that slot. The definition of 'similar' depends on the kind of >> index you create (see the predefined index specs in index.lisp for >> some examples). > > Ok, I'd feel better if the system were to promise me that it were not > to allow such a scenario. Yes, I agree. > I don't suppose there is any notion of a multi-slot index or a multi-slot > uniqueness constraint? Not at the moment, but I think it would be a useful addition to Rucksack. So if you have a nice design for this... > Also, presumably this uniqueness constraint is per-rucksack, not > globally for all instances of this class. Yes. > I wonder how subclassing affects this... I don't think I documented this, and I must admit I can't tell you from the top of my head. But have a look at the definition of RUCKSACK-MAYBE-INDEX-CHANGED-SLOT and the INCLUDE-SUPERCLASSES argument for RUCKSACK-SLOT-INDEX. >> All class and slot indexes are automatically added to the root set. >> So if you create an instance of a class that has an indexed slot, >> that instance will automatically be reachable from the roots and it >> won't be removed by Rucksack's garbage collector. > > Hmm... Ok, this I still don't quite get. when I make-instance a > persistent object, I should then be able to map-rucksack-roots to get > this instance? No. But if you MAKE-INSTANCE a persistent object that has a slot or a class index (or, to be more precise, if you MAKE-INSTANCE a persistent object that is added to a slot or class index), you can be sure that Rucksack's garbage collector won't remove that object behind your back. You're not supposed to use MAP-RUCKSACK-ROOTS to find such an object. But you indexed it, right? So you can use the indexes to find it. > On a related note, how do I go about explicitly deleting objects? Actually, that's the wrong question ;-) You don't explicitly delete an object, the garbage collector will delete it for you if it can't be reached from the root set. Just like in normal Lisp... If you really want to, it shouldn't be too difficult to delete an object from all slot indexes where it occurs. But you should probably ask yourself if you really need this before you do it. > I notice that delete-rucksack-root is not exported. is this > intentional? Yes. I don't expect that a normal Rucksack user would need this function. Arthur From ch-rucksack at bobobeach.com Thu Nov 30 19:44:57 2006 From: ch-rucksack at bobobeach.com (Cyrus Harmon) Date: Thu, 30 Nov 2006 11:44:57 -0800 Subject: [rucksack-devel] indexing issue? In-Reply-To: References: <42002F55-6253-465C-BC6F-33CE9A84DA80@bobobeach.com> <15FC081E-4C24-4CE6-8C5D-D6C3AE30AFA6@bobobeach.com> Message-ID: <0B87D3FA-6352-4804-B3D3-1CB93A373888@bobobeach.com> Ok, it's slowly starting to make sense to me. I feel like a C programmer approaching lisp and asking how to get the address of the result of (cons... :) On Nov 30, 2006, at 11:21 AM, Arthur Lemmens wrote: > Cyrus Harmon wrote: >> I don't suppose there is any notion of a multi-slot index or a >> multi-slot >> uniqueness constraint? > > Not at the moment, but I think it would be a useful addition to > Rucksack. > So if you have a nice design for this... not at the moment, but I'll file this away as something to think about. >> I wonder how subclassing affects this... > > I don't think I documented this, and I must admit I can't tell you > from the top of my head. But have a look at the definition > of RUCKSACK-MAYBE-INDEX-CHANGED-SLOT and the INCLUDE-SUPERCLASSES > argument for RUCKSACK-SLOT-INDEX. ok, I'll check it out when I get there... >>> All class and slot indexes are automatically added to the root set. >>> So if you create an instance of a class that has an indexed slot, >>> that instance will automatically be reachable from the roots and it >>> won't be removed by Rucksack's garbage collector. >> >> Hmm... Ok, this I still don't quite get. when I make-instance a >> persistent object, I should then be able to map-rucksack-roots to get >> this instance? > > No. But if you MAKE-INSTANCE a persistent object that has a slot > or a class index (or, to be more precise, if you MAKE-INSTANCE a > persistent object that is added to a slot or class index), you can > be sure that Rucksack's garbage collector won't remove that object > behind your back. or added with add-rucksack-root, I imagine. > You're not supposed to use MAP-RUCKSACK-ROOTS to find such an object. > But you indexed it, right? So you can use the indexes to find it. Oh? is using the index the only way to find it? Again, my SQL bias is showing through here, but I view indices as an optimization, rather than the canonical interface to the data. If I wanted to say, map- slots over a non-indexed slot, I assume that would still work, right? is map-rucksack-roots not a preferred way to find things? I notice that there is a rucksack-map-objects, which sounds reasonable, but that it is #+later'ed out. Can you shed some light on this? >> On a related note, how do I go about explicitly deleting objects? > > Actually, that's the wrong question ;-) > > You don't explicitly delete an object, the garbage collector will > delete it for you if it can't be reached from the root set. Just > like in normal Lisp... > > If you really want to, it shouldn't be too difficult to delete an > object from all slot indexes where it occurs. But you should probably > ask yourself if you really need this before you do it. Ok, but if you make-instance something with an index and it gets added to the index, surely there's a way to remove it from the index, no? >> I notice that delete-rucksack-root is not exported. is this >> intentional? > > Yes. I don't expect that a normal Rucksack user would need this > function. Ok, looks like i need to be using the rucksack-roots less, or at least not directly. Finally, one further question... what does rucksack do about cycles? Is there a way to break cycles or have rucksack do something else intelligent with them?Sorry if this is in the docs, but grepping for cycle isn't turning up anything useful. When I try to add an object that points to itself rucksack seems to spin forever. Thanks again, Cyrus From alemmens at xs4all.nl Thu Nov 30 20:26:15 2006 From: alemmens at xs4all.nl (Arthur Lemmens) Date: Thu, 30 Nov 2006 21:26:15 +0100 Subject: [rucksack-devel] indexing issue? In-Reply-To: <0B87D3FA-6352-4804-B3D3-1CB93A373888@bobobeach.com> References: <42002F55-6253-465C-BC6F-33CE9A84DA80@bobobeach.com> <15FC081E-4C24-4CE6-8C5D-D6C3AE30AFA6@bobobeach.com> <0B87D3FA-6352-4804-B3D3-1CB93A373888@bobobeach.com> Message-ID: Cyrus Harmon wrote: >> No. But if you MAKE-INSTANCE a persistent object that has a slot >> or a class index (or, to be more precise, if you MAKE-INSTANCE a >> persistent object that is added to a slot or class index), you can >> be sure that Rucksack's garbage collector won't remove that object >> behind your back. > > or added with add-rucksack-root, I imagine. Right. Or if you add it to any persistent datastructure (e.g. a persistent cons, or a persistent vector, or a persistent btree) that is reachable from the roots. > Oh? is using the index the only way to find it? No. It's really just like in 'normal' Lisp. You can decide to bypass the entire indexing structure that Rucksack provides, and just build your own persistent datastructures. Maybe you need a persistent queue of incoming messages, for example. You can build such a queue on top of Rucksack's persistent conses, persistent vectors or other persistent objects. You may not need any indexing for such a queue. As long as you put the head of the queue into the root set, you can do whatever you want. This is not a relational database, it's persistent Lisp objects ;-) > I view indices as an optimization, rather than the canonical > interface to the data. I agree, but maybe not in the way that you think. In Rucksack, the canonical interface to the data is other data. > If I wanted to say, map-slots over a non-indexed slot, I assume > that would still work, right? Well... at the moment it wouldn't signal an error, but it wouldn't find anything either. Maybe you're right: as long as there is a class index, it would be possible in principle to iterate over all instances of the class and do something equivalent to MAP-SLOTS for an indexed slot. But it's also possible to define persistent classes without a class index; in that case, there would be no way for MAP-SLOTS to find all instances of a class, and it couldn't do what you expect it to do. > is map-rucksack-roots not a preferred way to find things? It's one way. To find something you have to start with map-rucksack-roots or with some function that uses the indexing mechanisms. > I notice that there is a rucksack-map-objects, which sounds > reasonable, but that it is #+later'ed out. Can you shed some > light on this? My idea was to build some kind of Lisp equivalent to SQL's WHERE. But I didn't get around to designing or implementing that yet. > Ok, but if you make-instance something with an index and it gets > added to the index, surely there's a way to remove it from the index, > no? The easiest way is probably to use SLOT-MAKUNBOUND. This should sooner or later call RUCKSACK-MAYBE-INDEX-CHANGED-SLOT, which will call INDEX-DELETE to remove the association between the old slot value and the object instance from the index. > Finally, one further question... what does rucksack do about cycles? Nothing special, really. I'm not sure that I understand your question. > Is there a way to break cycles What kind of cycles would you want to break, and why? > When I try to add an object that points to itself rucksack seems > to spin forever. If it does, that's a bug. Can you show me the code that does this? Arthur From ch-rucksack at bobobeach.com Thu Nov 30 23:49:33 2006 From: ch-rucksack at bobobeach.com (Cyrus Harmon) Date: Thu, 30 Nov 2006 15:49:33 -0800 Subject: [rucksack-devel] indexing issue? In-Reply-To: References: <42002F55-6253-465C-BC6F-33CE9A84DA80@bobobeach.com> <15FC081E-4C24-4CE6-8C5D-D6C3AE30AFA6@bobobeach.com> <0B87D3FA-6352-4804-B3D3-1CB93A373888@bobobeach.com> Message-ID: On Nov 30, 2006, at 12:26 PM, Arthur Lemmens wrote: > Cyrus Harmon wrote: >> Oh?0 is using the index the only way to find it? > ... > This is not a relational database, it's persistent Lisp objects ;-) Indeed. Still trying to get my head around that concept fully. So does this mean that when I have an object of an indexed class I don't need to explicitly call add-rucksack-root? > The easiest way is probably to use SLOT-MAKUNBOUND. This should > sooner or later call RUCKSACK-MAYBE-INDEX-CHANGED-SLOT, which > will call INDEX-DELETE to remove the association between the > old slot value and the object instance from the index. Hmm... I'm confused, but I'll keep digging. >> Finally, one further question... what does rucksack do about cycles? > > Nothing special, really. I'm not sure that I understand your > question. Well, for starters there are cyclic lists and it looks like rucksacks answer to that is: Serializing circular lists isn't implemented yet. [Condition of type SIMPLE-ERROR] Restarts: 0: [ABORT] Abort # 1: [RETRY] Retry # 2: [ABORT-REQUEST] Abort handling SLIME request. 3: [TERMINATE-THREAD] Terminate this thread (#) Backtrace: 0: ((SB-PCL::FAST-METHOD RUCKSACK::SERIALIZE (CONS T)) # # #1=(1 . #1#) #) 1: ((SB-PCL::FAST-METHOD RUCKSACK::SAVE-OBJECT (T #1="#<...>" . #1#)) # # #> 58 # 337391780600000 NIL :SCHEMA NIL) 2: ((SB-PCL::FAST-METHOD RUCKSACK::SAVE-DIRTY-OBJECT (T #1="#<...>" . #1#)) # # #> # # 58 :SCHEMA NIL) 3: ((SB-PCL::FAST-METHOD RUCKSACK:TRANSACTION-COMMIT-1 (RUCKSACK:STANDARD-TRANSACTION RUCKSACK:STANDARD-CACHE RUCKSACK:STANDARD-RUCKSACK)) # # # # #) 4: ((LAMBDA (SB-PCL::.PV-CELL. SB-PCL::.NEXT-METHOD-CALL. SB- PCL::.ARG0. SB-PCL::.ARG1. SB-PCL::.ARG2.)) # # # # #) 5: (TEST-CYCLE) 6: (SB-INT:SIMPLE-EVAL-IN-LEXENV (TEST-CYCLE) #) 7: (SWANK::EVAL-REGION "(test-cycle) which is better than spinning for ever. >> Is there a way to break cycles > > What kind of cycles would you want to break, and why? Well, breaking them isn't the right answer, but somehow representing them in persistent storage would be nice. >> When I try to add an object that points to itself rucksack seems >> to spin forever. > > If it does, that's a bug. Can you show me the code that does this? Working on a test case. What I have is an object that contains a (non- persistent) object that points to itself. Which leads me to what is probably another fundamental misunderstanding on my part. What does rucksack do with objects of non-persistent classes? Here's my test: (defclass a-non-persistent-class () ((bogosity :accessor bogosity :initarg :bogosity))) (eval-when (:compile-toplevel :load-toplevel) (rucksack:with-rucksack (rucksack *test-rucksack* #+nil :if-exists #+nil :supersede) (rucksack:with-transaction () (defclass a-persistent-class () ((name :accessor name :initarg :name :index :string-index) (info :accessor info :initarg :info)) (:metaclass persistent-class) (:index t))))) (defun test-not-persistent-data-1 () (let ((np (make-instance 'a-non-persistent-class :bogosity 412))) (rucksack:with-rucksack (rucksack *test-rucksack*) (rucksack:with-transaction () (let ((p (make-instance 'a-persistent-class :name "moose" :info np))) (print (name p))))))) (defun test-not-persistent-data-lookup-1 () (rucksack:with-rucksack (rucksack *test-rucksack*) (rucksack:with-transaction () (rucksack:rucksack-map-slot rucksack 'a-persistent-class 'name (lambda (x) (print (list (bogosity (info x)) (name x) x))))))) (defun test-not-persistent-data-2 () (let ((np (make-instance 'a-non-persistent-class :bogosity 412))) (setf (bogosity np) np) (rucksack:with-rucksack (rucksack *test-rucksack*) (rucksack:with-transaction () (let ((p (make-instance 'a-persistent-class :name "moose" :info np))) (print (name p))))))) test-persistent-data-1 seems to work fine and the slot in a-non- persistent-class is even preserved, it seems. yay! but, when you go to run test-not-persistent-data-2 you get stuck on a loop. yes, perhaps this is a contrived situation, but it's the situation I find myself when trying to shoe-horn my existing classes into rucksack. So, in summary, there are two separate issues it seems, cyclic lists, which are not supported but which throw an error and persistent objects that contain objects that point to themselves which just hang. Thanks again for the insightful discussion and for rucksack in general! It's starting to get clearer. Cyrus