Break up rangestore into two different implementations.

[eawagner]

This is just a proposal to have one implementation that does not gather overlapping ranges and another that does (like the current implementation). The proposed implementation would follow the ext structure that we have used in other stores.

The reason for a second implementation instead of simply making it an option is that without having to worry about overlapping ranges, the store can handle more data types for example Strings.

Currently the problem for the rangestore is that it needs to be able to calculate the distance between two points to minimize the scan for the overlapping ranges. Without this calculation, ranges could be of any Comparable type instead of numerically backed types.

[cjnolet]

It sounds to me like you are proposing doing a simple scan with a starting point and an ending point... which we are doing in many of the other stores (entity, event, etc...) already. What's the use case?

[eawagner]

No, this proposal is simply that one implementation has the forward and reverse scans only from the current implementation, while an extension to that store adds the additional capability for overlapping scans to provide the full set of capalities that are in the current store.

There are several benefits that can be gained by not having to worry about scanning for overlapping ranges. For one you don't need to do a distance calculation which is currently required to prevent scanning the entire table. This means that we can have ranges for non-numerically based data types such as Strings or character based data. Additionally, it reduces the number of mutations required for each range that is stored in the table.

The use case for this is the want to be able to do range queries when you don't care about overlapping ranges (see Issue #14 comment). One instance where this would be useful is when the query range will always be larger than the ranges stored in the store.

[cjnolet]

I guess it seems more powerful (and easy to use) if you could just specify which one you want in a config (or in the constructor) rather than a different store. It doesn't seem like the table structure would be any different. or is it?

[eawagner]

The only difference in the table structure would be that there would be no distance mutation to allow for the calculation of max distance in the non-overlapping version.

This is similar to the blob store where the extended version has additional mutations for additional properties, but the basic functionality for storing the blobs is exactly the same.

[cjnolet]

But does this warrant having to make a completely new store? I'm not really liking how each separate bit of functionality warrants a completely new store. I'd like to see more of the simple options combined. If the only difference is that the maxDistance isn't used, why can't this be done in the same store? Pragmatically this may be showing how useful your object oriented design is, but practically, it's annoying that i can't just have an option to scan one way or the other.

[eawagner]

I am fine with that. Some of these "little" options have practical impacts on performance an storage requirements. For example simply storing the distance of each range because it is default adds 33% more to the storage requirements to a store where there may be no need for it.

I will leave things the way they are for this store however and close the ticket. It isn't worth it if noone sees the need.

[cjnolet]

I don't think the question was ever whether or not anyone sees a need. I personally think the proposed feature could be very useful. Maybe you are right about it being a separate store, though, I think it would be nice if I could just enable an option and be able to persist/query both ways.

[eawagner]

All things the same, there really isn't a need for this store right now. It was always more of a thought experiment. I think when there is a real implementation need then maybe we can readdress this