> if you don't need sorting you can just call get-instances-by-class and
> sort stuff manually.
Not really acceptable for me, unfortunately -- or at least I guess
so. What would the speed penalty be if I'd sort everything on the
Lisp side?
> i've taken one more look at cursor code, it seems rep
> i think there are no, we just didn't get to it as floats aren't used
> as frequently as integers and strings are. i think it would be
> enough to modify functions postgres-format and postgres-value-to-lisp
> to support floats and it will work.
I don't have an immediate need for floats as sort
LPP> I can sort out the objects with NIL values later on the Lisp
LPP> side -- that's acceptable. But those objects not showing up
LPP> at all in the index is pretty bad indeed!
if you don't need sorting you can just call get-instances-by-class and
sort stuff manually.
i've taken one more look
LPP> While we're at it, I remember running into a similar problem
LPP> with float slots.
yep, if it sees float it will upgrade column to "object" type and
sorting will be lost
LPP> Are there any hidden difficulties in implementing float sort
LPP> support?
i think there are no, we just didn't
While we're at it, I remember running into a similar problem
with float slots.
Are there any hidden difficulties in implementing float sort
support?
___
elephant-devel site list
elephant-devel@common-lisp.net
http://common-lisp.net/mailman/listinfo/ele
> 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..
That would be a good start.
I can sort out the obj
??>> 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 f
Hi Alex,
> LPP> Is there any sense behind this result? Are NIL values somehow
> LPP> special to the secondary indexing mechanism?
>
> it is somehow special in map-index, and inherently in
> GET-INSTANCES-BY-RANGE --
> if start is NIL it starts from beginning, it end is NIL it iterates to the
>
LPP> Is there any sense behind this result? Are NIL values somehow
LPP> special to the secondary indexing mechanism?
it is somehow special in map-index, and inherently in
GET-INSTANCES-BY-RANGE --
if start is NIL it starts from beginning, it end is NIL it iterates to the
end, so (NIL, NIL)
ran
