Quotes in the underlying bytes in the column visibility will get
stripped during evaluation. They are only used for parsing the
expression, not for comparing with authorizations.
Christopher L Tubbs II
On Mon, Jul 15, 2013 at 1:47 PM, Ed Kohlwey <[EMAIL PROTECTED]> wrote:
> My intention was for the strings to be interpreted as java code - so the
> quotes are not part of the authorization name. The labels would be a&b and
> "a"&b (if we're talking bare strings).
> The issue I'm really trying to get at is that a programmer would think of
> these two labels as equivalent. This is a natural assumption for a
> programmer who generally thinks that escape characters or quotes don't
> contribute to the meaning of an expression because thats how programming
> languages usually work. But it sounds like thats not the case.
> On Mon, Jul 15, 2013 at 9:23 AM, Keith Turner <[EMAIL PROTECTED]> wrote:
>> On Sat, Jul 13, 2013 at 7:32 PM, Ed Kohlwey <[EMAIL PROTECTED]> wrote:
>> > I just noticed something as I was hacking today on the trunk - does the
>> > column visibility code (with escape sequences) accommodate visibilities
>> > that are equivalent but not stored using the same byte representation? My
>> > assumption is no...
>> > Ie., is the visibility "a&b" equivalent to "\"a\"&b" for the purpose of
>> > max versions iterator, etc.?
>> I do not think the visibility "a&b" and "\"a\"&b" are equivalent. The
>> escaped quotes are not ignored, they are part of the label. To
>> see "\"a\"&b", you would need to pass an authorization of: "a"&b to the
>> scanner. Passing an authorization of a&b to scan would not see a column
>> labeled with "\"a\"&b".
>> The exact bytes you pass to ColumnVis is whats stored. The colvis bytes
>> are used for lexicographic sorting w/o interpreting their contents.
>> So "a&b" and "\"a\"&b" would sort to different places.
>> If you did store something thats logically equivalent like a&b and b&a,
>> then these would still sort to different places. ColumnVisibility has a
>> flatten() function that may help in some cases, but it will not always
>> normalize two expressions that are logically equivalent to the exact same