> 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 _______________________________________________ elephant-devel site list elephant-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/elephant-devel
