[elephant-devel] Bug, omission, or desired behaviour?

[Alain Picard]

"Leslie P. Polzer"
<sky at 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