"Leslie P. Polzer"
<s...@viridian-project.de> writes:
> Would you propose that Elephant check the type as well
> when serializing slots?
I'm a bit of two minds about it. I might be jaundiced in my
view because the systems I've used before was an O-R mapping
system, and there it made sense to assert in lisp---if you
didn't you eventually failed to store you data because of
a mismatch between the lisp type and the SQL column type.
Hyperspec 7.5.3 states:
> * The contents of a slot will always be of type (and T1 ... Tn) where
> T1 ...Tn are the values of the :type slot options contained in all of
> the slot specifiers. If no slot specifier contains the :type slot
> option, the contents of the slot will always be of type t. The
> consequences of attempting to store in a slot a value that does not
> satisfy the type of the slot are undefined.
So, the current "undefined" behaviour of Elephant is to "do the right
thing". Another valid undefined behaviour might be to assert.
I think I hadn't analyzed this through before reporting the "bug".
Now that I realize it's a lisp semantics issue (rather than a
DB type safety issue) I'm inclined to think maybe the way to handle
it is as SBCL does (which I didn't know about - thanks for the tip!)
and let the user choose the correct behaviour. So we could have
a flag *ELEPHANT-ENFORCE-SLOT-TYPE-SAFETY-P* (defaulting to nil)
to catch such violations and turn them into asserts, on both
serialization and deserialization.
This is, obviously, a very low priority matter, and truthfully, I'm
not sure I'd use it, at least not until my application was fully
debugged. Also, I think it would make migration issues when classes
are redefined even hairier than they currently are.
So, no --- I'm not proposing it. :-)
--Alain
_______________________________________________
elephant-devel site list
elephant-devel@common-lisp.net
http://common-lisp.net/mailman/listinfo/elephant-devel
