Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
Accumulo >> mail # dev >> feedback on Typo

Copy link to this message
Re: feedback on Typo
One suggestion I'd make is to force users to name their tuples by making
the tuple types abstract. This won't help your complexity but IMHO makes
code more readable.

This an issue of java style, but there's nothing more irritating than
tuples floating around code without having an obvious explanation of "why
do these things belong together"?

On Wed, Aug 15, 2012 at 9:38 AM, Keith Turner <[EMAIL PROTECTED]> wrote:

> On Wed, Aug 15, 2012 at 9:19 AM, Ed Kohlwey <[EMAIL PROTECTED]> wrote:
> > I think its not just about types, but specifically primitive types and
> > tuples.
> Right.  And sorting is another very important aspect.   User want to
> do things like store dates that sort in reverese order as part of a
> tuple in the row.  We tell them its possible if they encode their data
> in a certain way.  And we also tell them "oh, BTW if you have binary
> data in your tuple it can be tricky to get it right".  So one goal of
> Typo is to make this easier for users.   I think something like the
> following would do this and get the lexicographic sort order correct.
> class RDTypo extends Typo<Pair<Long, Date>,String,String,Text> {
>   public RDTypo() {
>     super(new PairLexicoder<Long,Date>(new LongLexicoder(), new
> ReverseLexicoder<Date>(new DateLexicoder())),
>              new StringLexicoder(), new StringLexicoder(), new
> TextLexicoder());
>   }
> }
> I so wish that Java had typedef, it could make the Typo API much more
> concise.  I never thought I would actually miss C++ template
> programming :)  I still need to do some more research on Java generics
> to see if I can make things more concise.
> >
> > So its avoiding being a full-fledged ORM solution like Gora.
> >
> >
> >> Am I right in assuming that this is about simplifying the API for
> >> storing typed data in the key, and not about providing a mechanism for
> >> query. Isn't this really just about storing stuff you've already
> >> decided was a good structure for whatever your query mechanism is?