Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 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
>> >>
>>
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB