??>> question is _why_ should you use GET-INSTANCES-BY-RANGE when
??>> you can do this via GET-INSTANCES-BY-VALUE?
LPP> Because I need sorting... ideally the NIL values should just be
LPP> clustered at the end or beginning of the sorted space.
it seems you're using db-postmodern, i have bad news for you -- postmodern
backend supports correct sorting _only_ if all values are either interger,
or string. if you ever insert NIL there, sorting will be random. yep, i know
it sucks, but it's a price we pay for using SQL directly.
actually supporting slot type (OR STRING NULL) is easier than supporting
arbitrary type combinations -- we can translate NIL to SQL NULL, so NIL
values
will be clustered, and rest will be sorted, but it's still considerable
amount of work, and it's tricky to support all cases..
LPP>> Is there any sense behind this result? Are NIL values somehow
special to the secondary indexing mechanism?
i've found why it's such -- there are actually checks in btree code,
introduced by patch:
[db-postmodern removed possiblity of using NIL as a key in btrees
Henrik Hjelte<[EMAIL PROTECTED]>**20071124163828]
it works in pretty nasty way -- if key is NIL it silently ignores
insert into btree. a problem is if NIL wasn't ignored it will
upgrade btree key type to "object" -- that means that
sorting won't work. iirc Henrik was annoyed with this behaviour,
so he've just banned all NILs. this means GET-INSTANCES-BY-VALUE
won't work either -- those object simply won't be in indices.
this appears to be pretty bad, i'll check if i
can fix this..
_______________________________________________
elephant-devel site list
elephant-devel@common-lisp.net
http://common-lisp.net/mailman/listinfo/elephant-devel
