the RangeEnabled option now has no effect, but it still exists in the API. A few
tests still use it to ensure this. This would only be considered a breaking
change if someone was relying on Pilosa to enforce the RangeEnabled: false
option to prevent fields being created in certain frames. This seems unlikely.
This to decouple the implementation of recalculating caches from the
structure of the hierarchy: holder > index > frame > view > fragment.
See [Law of Demeter](https://en.wikipedia.org/wiki/Law_of_Demeter).
This PR adds the ability to import field values into RangeEnabled frames
using the `pilosa import` command.
Example:
```
pilosa import -i i -f f --field foo sample-vals.csv
```
imports data from sample-vals.csv, which contains data in the format:
```
[ColumnID, Value]
```
Also fixes a bug where `frame.rangeEnabled` was not being set on frame creation.
The PQL looks like:
```
Range(frame=f, field0 >< [200,610])
```
One thing I noticed while implementing this is that it doesn't seem
like `FieldRange()` is used in either `Frame` or `View`; the Executor
calls `Fragment.FieldRange()` directly. The problem with this is that
the offset logic is calculated in the Frame, but since the Executor
doesn't go through Frame, then the Executor also has to calculate
the offset before calling `Fragment.FieldRange`. We should unify this
logic somewhere. Note, this applies to both `FieldRange` and
`FieldRangeBetween`.
This required changing the Holder test utility Reopen, since in those cases we needed to close the file before making permission changes that Close() was failing silently on.
This commit adds `FieldRange()` to the `Frame`, `View`, and
`Fragment` types. It accepts an operator & a predicate and
returns a bitmap of matching field values.
