There's only the one direct use, and a lot of indirect uses via
IdentityQueryFilter. Finally, there are some slice tests in the
python system tests ("nosetests").
On Fri, Mar 30, 2012 at 7:25 PM, Mark Dewey wrote:
> I'm new working on the project and looking for the unit tests for
> SliceQueryFi
>
> If you don't need selected updates and having something as compact as
> possible on disk make a important difference for you, sure, do use blobs.
> The only argument is that you can already do that without any change to
> the core.
The thing that we can't do today without changes to the core
On Fri, Mar 30, 2012 at 6:01 PM, Daniel Doubleday
wrote:
> But decomposing into columns will lead to more of that:
>
> - Total amount of serialized data is (in most cases a lot) larger than
> protobuffed / compressed version
At least with sstable compression, I would expect the difference to
not
Do we also need to consider the client API?
If we don't adjust thrift, the client just gets bytes right?
The client is on their own to marshal back into a structure. In this
case, it seems like we would want to chose a standard that is efficient
and for which there are common libraries. Protobuf
> Just telling C* to store a byte[] *will* be slightly lighter-weight
> than giving it named columns, but we're talking negligible compared to
> the overhead of actually moving the data on or off disk in the first
> place.
Hm - but isn't this exactly the point? You don't want to move data off disk
