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 # user >> Incorrectly setting TKey causes NPE (to nobody's surprise)


Copy link to this message
-
Re: Incorrectly setting TKey causes NPE (to nobody's surprise)
The tradeoff would be convenience versus complexity in the API. I would
lean towards having fewer ways to create a Key.

Has this debate played out before?
http://www.wikivs.com/wiki/Python_vs_Ruby#Philosophy

Adam

On Tue, Jun 26, 2012 at 9:17 AM, David Medinets <[EMAIL PROTECTED]>wrote:

> I play 'stupid developer' fairly well. I saw something that defines a
> key and started to use it. If I set row, cf, cq, and visibility then
> the iterator works fine.
>
> Is there any reasons why default values of "" should not be provided
> for cf, cq, and visibility?
>
> On Tue, Jun 26, 2012 at 9:09 AM, Marc P. <[EMAIL PROTECTED]> wrote:
> > I realized that Mr Slacum and I addressed the concern of using thrift;
> > however, perhaps you are doing something internally. Have you tried
> > setting the stop key on the TRange just for S&Gs?
> >
> > On Tue, Jun 26, 2012 at 9:03 AM, Marc P. <[EMAIL PROTECTED]> wrote:
> >> Why are you using that accepts the thrift key and range? They're
> >> internal communication objects within accumulo. I haven't looked the
> >> code directly, but they're likely contracted to be set in a different
> >> manner.
> >>
> >>
> >> On Tue, Jun 26, 2012 at 8:56 AM, David Medinets
> >> <[EMAIL PROTECTED]> wrote:
> >>> I did this:
> >>>
> >>> TKey tKey = new TKey();
> >>> tKey.setRow(row_id.getBytes());
> >>>
> >>>
> >>> TRange tRange = new TRange();
> >>> trange.setStart(tKey);
> >>>
> >>> scan.setRange(tRange);
> >>>
> >>> Iterator iterator = scan.iterator();
> >>> iterator.hasNext();
> >>>
> >>> This resulted in an NPE in:
> >>>
> >>> org.apache.accumulo.core.data.Key.rowColumnStringBuilder(Key.java:472)
> >>>
> >>> While I have no real objection to this NPE (my code is clearly
> >>> deficient), I wonder if a more cogent error message is possible.
> >>> Should there be guard statements somewhere to ensure a valid object?
>
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