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 >> Key.getColumnFamilyAsBytes - comments about suggested new method?


Copy link to this message
-
Re: Key.getColumnFamilyAsBytes - comments about suggested new method?
For efficiency reasons, I'd leave the methods that take a Text object
as-is. This avoids a third copy of the data when a user actually wants it
in Text form.

On Tue, Nov 13, 2012 at 12:25 PM, David Medinets
<[EMAIL PROTECTED]>wrote:

> In Key.java, I see this:
>
>   public Text getColumnFamily(Text cf) {
>     cf.set(colFamily, 0, colFamily.length);
>     return cf;
>   }
>
>   public Text getColumnFamily() {
>     return getColumnFamily(new Text());
>   }
>
> in TabletServerBatchDeleter, I see this:
>
>         Mutation m = new Mutation(k.getRow());
>         m.putDelete(k.getColumnFamily(), k.getColumnQualifier(), new
> ColumnVisibility(k.getColumnVisibility()), k.getTimestamp());
>
> The change I recently committed would allow using byte arrays as
> arguments to putDelete. It seems adding a method to Key like the
> following would eliminate creating the Text object:
>
>   public byte[] getColumnFamilyAsBytes() {
>     byte[] buffer = new byte[colFamily.length];
>     System.arraycopy(colFamily, 0, buffer, 0, colFamily.length);
>     return buffer;
>   }
>
> I don't want to head down a twisty windy path removing Text objects
> but does it make sense to reduce reliance on them?
>
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