[elephant-devel] Re: NIL values in secondary indices

[Leslie P. Polzer]

> 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 representing
> NIL as NULL is possible, but it will make code quite hairy, as SQL
> treats NULLs differently from normal values, it needs sort of two modes
> of operation.

Some added IFNULL clauses won't help, I guess?


> so i'm not sure if it's worth complicating code with this
> -- it might be cleaner to implement more general solution instead, to
> keep different types in different tables.

Sounds like a major refactoring, or at least one for which I
don't have the resources right now.


> but it might be simplier to support nils on map-index level rather than
> on btree/cursor level -- so get-instances-by-value will do SQL
> query like this:
>
>   SELECT * FROM class_index_x WHERE class_index_x.key
>   NOT IN (SELECT key FROM secondary_index_x)
>
> and get-instances-by-range can detect case when range includes NIL
> values and append append aforementioned query results to range results.
> so there will be no nulls in secondary indices, but they will be visible to
> class indexing APIs.

Well, at least it would be cheaper than doing the set difference
on the Lisp side.

What solution(s) could you afford to do right now?

I could ponder working on the refactoring solution if we can somehow
divide the work and when I know better what it would involve.

  Leslie