[elephant-devel] Test

[Ian Eslick]

I haven't been able to test my little patch to controllers.lisp that
should handle upgrading from 0.5.0 db's to 0.6.0 db's.  Could someone
run a quick test on my behalf?  I'm happy to help guide a short
debugging cycle (it's a trivial change - recognize deprecated classes
and create the replacement class instead). 

A more robust solution would be to migrate and overload the way
persistent classes are serialized for one store and deserialized for
another. 

Probably we need to add a way to store simple database metadata (list
structure as a registry with strings, symbols and numbers) that contains
version and other information.  Upon opening we can look up version
specific upgrade code if the elephant version is higher than the
database version and upgrade upon open, prompting the user for a target
spec if upgrade-by-copy or in-place.  The easiest way to do this is to
reserve some keywords in the root by using a reserved value such as
'elephant::*elephant-metadata*.

In fact I recommend we agree on a standard for this and ensure that
0.6.0 contains this metadata so we can at least recognize 0.6.0+ db's
when they are opened.  I apologizing if I'm repeating earlier
discussions.  I've been effectively offline for the past week and a half.

Proposal:

(add-to-root 'elephant::*elephant-metadata*
    '((version 0 6 0)      ;; format (version major minor sub1 ... subN)
      (spec :bdb "foo")  ;; format (spec <spec as list>)
      (lisp . :sbcl)))         ;; format (lisp . <lisp-type>)

In fact we might do the following as well:
1) assert an error when add-to-root is used by the user to write
elephant::*elephant-metadata*
2) create a simple interface around add-to-root which provides metadata
access

(defmethod get-metadata (tag &optional (sc *store-controller*))
   (let ((entry (assoc tag (get-from-root *elephant-metadata*)))
       (when entry
           (cdr entry))))

(defmethod set-metadata (tag value &optional (sc *store-controller*))
   (unless (reserved-metadata-tags tag)
      ...))

This way we make sure the user cannot shoot themselves in the foot by
overwriting reserved
metadata tags or the reserved root keyword.  Migration should handle the
reserved keyword
specially by not migrating reserved tags but migrating any user-defined
tags.

This might be overkill as users may only need access to
system-maintained metadata rather
than yet another namespace for storing data as the root should function
equally well...

Thoughts?
Ian