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 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
Copy link to this message
-
Re: Generic Supertypes/Pluggable Client
On Fri, Jul 5, 2013 at 10:33 AM, Ed Kohlwey <[EMAIL PROTECTED]> wrote:

> > Just a knee-jerk reaction here, but allowing a user to provide Text,
> String
> > or byte[] is painful?
> >
> > I've always viewed it as String if I want to be lazy, and byte[] or Text
> > when I'm more concerned about performance and don't want to be making new
> > objects for every record I need insert into Accumulo.
>
>
> The problem isn't that people are allowed to provide different types, the
> problem is that the types are inconsistent. Value still has only one
> method

to get data out, which is get() and returns a byte array. Key has the
> option of Text or ByteSequence, neither of which are easily compatible with
> CharSequence. CharSequence, Text, or byte[] are allowed as parameters to
> Range. Scanner.fetchColumn() is only for Text, unless you use the version
> that takes a Column but that is also very inelegant. Every single
>

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.
> application I've worked on with Accumulo has a utility class with methods
> to help convert between these types, and then also the application's own
> data model. The application code is always unnecessarily inelegant and
> confusing to new people on the project. Explaining the necessity of the
> (frankly bizarre) type conversion scaffold always makes programmers who are
> new to the platform make a stinkface and ask why it is still written the
> way it is.
>
+
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
+
Ed Kohlwey 2013-07-08, 14:22
+
Christopher 2013-07-08, 16:28
+
devramiyer1@... 2013-07-06, 04:11
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