A follow up question. Will it be possible to migrate existing indexes
in a future release as part of the upgrade path to support LT and LTE
ops without equal? In the meantime in my Datanucleus Plugin I was
thinking I could do something like the following. It's not efficient
for space, but it will work and should hopefully be relatively efficient
LT and LTE ops can be though of as the distance from the MAX value of
any given data type. For instance, if I had a data type :"ubershort",
which goes from -200 to 200, I could say that an expression of <= 0 is
really >= (distance) 200 from the maximum. I could use this equation to
calculate the "distance" to persist a distance value in a column named
"<colName>_reverse". Which would effectively give me a reverse index.
Then the value would simply be
storedValue = MAXVALUE-userVal.
From there, whenever the user issues a < <= query, I would simply
translate the value via the above equation and < becomes > and <=
becomes >=. Aside from the space issue of storage, do you see any other
problems with this approach for a 0.7 compatible version of my plugin?
On Wed, 2010-10-13 at 14:00 +1300, Todd Nine wrote:
SENIOR SOFTWARE ENGINEER
todd nine| spidertracks ltd | 117a the square
po box 5203 | palmerston north 4441 | new zealand
P: +64 6 353 3395 | M: +64 210 255 8576
E: email@example.com W: www.spidertracks.com
On Tue, 2010-10-12 at 18:47 -0500, Jonathan Ellis wrote:
On Tue, Oct 12, 2010 at 6:34 PM, Todd Nine wrote:
Currently there is only indexing for LT and LTE expression when an EQ
operator is present. Will it be possible to use the LT and LTE ops
without an EQ by the 0.7.0 release? No.
If not, which of the following
would be more efficient?
1. Creating a dummy column of 1 byte that is indexed.
This is basically the same as doing a full range scan, only less efficient.
2. Use my previous indexing scheme of 2 Super CF for longs and strings
to get my < <= operations. Where I use the following scheme.
I'm not sure I follow but if it's better than doing a full range scan
then it is better than 1. :)