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 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. 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. 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. drawback of this "workaround" solution is that it can be slow when table goes large, as it needs to traverse whole index. so there are three options how to do this: * via NULLs and hairy cursor code * major restructuring to support multiple types * workaround to support nils on indexing API level, with some overhead _______________________________________________ elephant-devel site list elephant-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/elephant-devel
