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

Switch to Plain View
Accumulo >> mail # dev >> Generic Supertypes/Pluggable Client


+
Ed Kohlwey 2013-07-05, 11:59
+
Josh Elser 2013-07-05, 12:39
+
Josh Elser 2013-07-05, 13:50
+
Ed Kohlwey 2013-07-05, 14:38
+
Keith Turner 2013-07-05, 17:13
+
Ed Kohlwey 2013-07-05, 14:33
+
Keith Turner 2013-07-05, 16:40
+
Josh Elser 2013-07-05, 17:07
+
Ed Kohlwey 2013-07-05, 17:31
+
Ed Kohlwey 2013-07-05, 17:27
+
Christopher 2013-07-05, 20:29
Copy link to this message
-
Re: Generic Supertypes/Pluggable Client
What do you think about making something like a SecurityLabelStream or
similar? That does an depth first traversal of the label expression?
On Fri, Jul 5, 2013 at 4:29 PM, Christopher <[EMAIL PROTECTED]> wrote:

> On Fri, Jul 5, 2013 at 1:27 PM, Ed Kohlwey <[EMAIL PROTECTED]> wrote:
> >> It would be very nice if the types you mentioned were more consistent
> >> across the API.  Personally I would like to see byte[] and ByteSequence
> >> fully supported across all of the APIs related to reading and writing
> data.
> >>   We added support for byte[] to mutation in 1.5. Thinking back, we
> should
> >> have added support for ByteSequence too.
> >
> >
> > +1. If we make everything tie back to ByteSequence and make the
> > serialization/deserialization logic pluggable, then everyone will be
> happy.
> > Do you have any ideas based on the sketch I included that would help make
> > this better for all types, not just byte[]?
>
> I'd be very cautious about making *everything* tie back to
> ByteSequence. Some things, are more constrained than bytes... such as
> Column Visibilities, which we assume are human-readable strings, and
> it'd be more appropriate to tie it back to CharSequence than
> ByteSequence in the API, even though internally it's just bytes. The
> bytes we store for this should really be UTF8-encoded characters.
> Table names are another place where we use Text sometimes in the API
> to refer to something containing a String/CharSequence and cannot be
> arbitrary bytes... though I don't think your proposal affects that
> part of the API as much.
>
> --
> Christopher L Tubbs II
> http://gravatar.com/ctubbsii
>
+
Christopher 2013-07-08, 16:28
+
devramiyer1@... 2013-07-06, 04:11