accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ed Kohlwey <ekohl...@gmail.com>
Subject Re: Quoted visibility equality?
Date Mon, 15 Jul 2013 17:47:37 GMT
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 <keith@deenlo.com> wrote:

> On Sat, Jul 13, 2013 at 7:32 PM, Ed Kohlwey <ekohlwey@gmail.com> 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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message