[elephant-devel] Key dangers.

[Ian Eslick]

William,

What distribution are you using?  There is an issue with unicode lisps
that has resulted in these differences and it's possible that the system
is not yet properly systematic.

Everyone,

I've been looking at a fix for 0.5.0 to 0.6.0 upgrades which is
essentially a deprecated symbol map that will take symbols defined in
the elephant package and move them to symbols defined in the sleepycat
package.  This would be invisible to users.  I just haven't had a chance
to test it yet.

In general I agree with Robert's comments about upgrading.  The current
migration code would be easy to turn into a database serializer that
would allow you to dump and reload an entire db in a reasonable way that
was independent of a specific backend.  I won't be able to get to this
for awhile but I'm happy to engage in a discussion if someone would like
to implement it.

Regards,
Ian

William Halliburton wrote:
>
> I am new so this is probably old news. Maybe need to place warning in
> manual under btrees.
>
> Not a bug, just a pain in the a...
>
> Been tracking a wierd behavior when I was using (get-value str *db*)
> and I could not get out what I put in.
>
> Tracked it down to the keys being of different string types. One of
> simple-base-string and the other of (simple-array character).
>
> (setf (get-value (namestring #p"asd") *db*) "foo")
>
> (get-value "asd" *db*) -> NIL
>
> Section 2.9 mentions that the BTrees hash on value via the
> serialization and i'm sure that the two string type serialize
> differently. Maybe a line like:
>
> "Hashing on strings of different types will result in separate hash
> entries."
>
> Thank you,
> William Halliburton
> ------------------------------------------------------------------------
>
> _______________________________________________
> elephant-devel site list
> elephant-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/elephant-devel