On May 28, 2007, at 9:26 AM, Joubert Nel wrote:
On Mon, 2007-05-28 at 08:51, Ian Eslick wrote:
A few clarifications:
Standard persistent classes are not saved by default. To get access
Ian, when are objects that are instanced from persistent classes
saved?
I simply call (make-instance) on the following class definition:
(defclass risk ()
((title :accessor title :initarg :title :initform ""))
(:metaclass elephant:persistent-metaclass)
(:index t))
the resulting object is immediately saved/persisted by Elephant...
I don't want to force users to take on the indexing overhead for all
persistent classes. The addition of the class :index option is what
ensures that it will be saved. This option is added by default if
any slot is indexed.
to a class via the map-class operator the class or a slot of the
class must be declared as :indexed. If a slot is indexed, then that
value can be used as a key for the object via the get-instances-by-
value interface. Moreover, you can have duplicate slot values and
get-instances-by-value will return all the objects having that slot
value.
Understood - this is what I got from the documentation as well.
Think of the root more like a hash table (single key-value pair)
instead of a set or collection. The simple get-value interface would
be more complex if it could return multiple values.
My impression until I saw how persistent objects behave was that
everything you want to store via Elephant had to be "rooted".
Did you read through the tutorial in the new manual? I thought I put
hints into the section on roots that you can store via indexed
classes and then the details should have been covered in the indexing
part of the tutorial. Do you have suggestions on how we can clarify
this point?
It is poor coding practice to use system-assigned OIDs. In future
versions of elephant OIDs may change over time due to GC, auto
recovery of oid space, etc. It's sort of like using the physical
address of an object in a C++ program. There is a legitimate way to
use OIDs outside of elephant, but we haven't yet defined an interface
for users to do so (for example you might want to use OIDs to create
many-to-many maps or efficient persistent sets)
Thanks for this insight. Many-to-many maps and sets are exactly
what I'm
trying to achieve.
I found a newly released UUID package for Lisp -
http://www.cl-user.net/asp/libs/uuid
I'm going to explore using this instead of OIDs.
We would be interested in a solution that we could integrate as a
contrib or as a standard component of elephant. I wrote a many-to-
many map awhile back that was just a btree where the key was the
source OID and the targets were a vector of OIDs (assuming that the
cross product was populated). If you wanted to be able to to do the
reverse you just create two of these btrees and ensure that they are
always synchronized. I'm sure there are more efficient solutions,
but this is relatively simple.
There is already a persistent set class (PSET), but you don't want to
be doing alot of operations on persistent sets because you can't
reclaim the intermediate products. There should be a tutorial
section on PSETs that talks about this.
Joubert
_______________________________________________
elephant-devel site list
elephant-devel@common-lisp.net
http://common-lisp.net/mailman/listinfo/elephant-devel
_______________________________________________
elephant-devel site list
elephant-devel@common-lisp.net
http://common-lisp.net/mailman/listinfo/elephant-devel
