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?
Ed Kohlwey 2013-07-15, 17:47
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
>