[bknr-devel] bknr.indices, the slot NIL is missing from the object

[Klaus Unger]

Hi Hans,

thanks for the promt response! The code I used was from the datastore-manual 
page 23. When adding the id slot name I run into the following problem: I use 
cl-prevalence for serialization. When restoring id-objects I do this 
without-auto-id, so the objects are created having the id slot unbound and 
assigned later on. This leads to duplicate entries in the class-index and 
thus inconsitency. I was not sure what happens if there are multiple objects 
having a unique-index slot set to Nil.

Instead of optionaly binding the id parameter in the constructor I now use an 
initform that at least binds the auto-id or Nil. Is this a good idea?:

Best regards
  Klaus

(defvar *id-counter* 0)
(defvar *auto-id* T)

(defmacro without-auto-id (&body body)
  `(let ((*auto-id* Nil))
     , at body))

(defun next-id ()
  (when *auto-id*
      (incf *id-counter*)))

(defclass id-object ()
    ((id
      :reader get-id
      :initform (next-id)
      :index-type unique-index
      :index-initargs (:test #'eql)
      :index-values find-all-id-objects
      :index-reader find-object-with-id))
  (:metaclass indexed-class)
  (:class-indices
    (classes :index-type class-index
                 :index-initargs (:index-superclasses t)
                 :slots (id)
                 :index-reader find-all-id-objects-with-class)))

Am Donnerstag, 21. Februar 2008 07:26:02 schrieb Hans Hübner:
> Hi Klaus,
>
> the class-index needs to know a slot that it uses for indexing the
> objects.  This slot is the unique ID that the index works on.  It must
> be added to your base class, but as you can see in the corrected
> example below, that should not be much of a problem.
>
> Note that the :INDICES option in an INDEXED-CLASS either accepts a
> predefined index or initargs to create a fresh index.  It is confusing
> to mix both initargs and the :INDEX option (which specifies the
> preexisting index *CLASS-INDEX* to be used).  I added code to detect
> this case.  More error checking would certainly be helpful, so please
> report problems when you encounter them and I'll try to make the code
> generate better diagnostics.
>
> Please let us know if you have further questions.
>
> Hans