Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
Accumulo >> mail # dev >> Quoted visibility equality?


Copy link to this message
-
Re: Quoted visibility equality?
Yes, that is correct. As Eric pointed out, this is unavoidable, and is
already prone to happen with equivalent expressions ("a&b" vs. "b&a").

--
Christopher L Tubbs II
http://gravatar.com/ctubbsii
On Mon, Jul 15, 2013 at 3:46 PM, Ed Kohlwey <[EMAIL PROTECTED]> wrote:
> They are not used for evaluation of the labels, however they are used for
> evaluation for the purposes of Max versions, etc. right? Because the actual
> bytes representing the security expression would be different, right?
> On Jul 15, 2013 3:41 PM, "Christopher" <[EMAIL PROTECTED]> wrote:
>
>> 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
>> http://gravatar.com/ctubbsii
>>
>>
>> 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
>> >> new
>> >> > 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
>> >> the
>> >> > 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
>> >> expression.
>> >>
>> >> Keith
>> >>
>>