Mark, You're right, my answer was totally misdirected.
The real reason is that TKey is not very user-friendly is that it is auto generated from the code in core/src/main/thrift/data.thrift. We don't intend for these auto-generated classes to be part of the public API. Also, we don't hand-code them (anymore) to make them convenient because we are likely to re-generate them when we upgrade Thrift in the future. Bottom line: don't use classes that are in a *.thrift package in your client code. Adam On Tue, Jun 26, 2012 at 10:31 AM, Marc P. <marc.par...@gmail.com> wrote: > I don't agree with that last promotion. From a usability perspective, > I think it would be better to either require all arguments or allow > them not to be set, instead of throwing an exception. This will create > confusion, especially with people unfamiliar with the stack, as > evidenced by David's question. > > On Tue, Jun 26, 2012 at 10:20 AM, Adam Fuchs <afu...@apache.org> wrote: > > 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 < > david.medin...@gmail.com> > > 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. <marc.par...@gmail.com> 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. <marc.par...@gmail.com> > 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 > >> >> <david.medin...@gmail.com> 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? > > > > >
