Home | About | Sematext search-lucene.com search-hadoop.com
 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?
>