The Java language isn't very amenable to Tuple APIs as there are several
(mutually exclusive?) tradeoffs that must be made, each with their pros and
cons. What advantage is there of Beam providing its own tuple API vs.
letting users pick whatever tuple library they want and using that with
Beam?
(I suppose we're already using and encouraging AutoValue which covers a lot
of tuple cases.)
On Tue, Dec 13, 2016 at 8:20 AM, Aparup Banerjee (apbanerj) <
apban...@cisco.com> wrote:
> We have created one. An untagged Tuple. Will be happy to contribute it to
> the community
>
> Aparup
>
> > On Dec 13, 2016, at 5:11 AM, Amit <amitsel...@gmail.com> wrote:
> >
> > I'll add that I know of Beam's PTuple, but my question is about much
> > simpler Tuples, untagged.
> >
> > On Tue, Dec 13, 2016 at 1:56 PM Jean-Baptiste Onofré <j...@nanthrax.net>
> > wrote:
> >
> >> Hi Amit,
> >>
> >> as discussed together, I think a Tuple abstraction would be good in the
> >> SDK (more than in the data format extension).
> >>
> >> Regards
> >> JB
> >>
> >>> On 12/13/2016 11:06 AM, Amit Sela wrote:
> >>> Hi all,
> >>>
> >>> I was wondering why Beam doesn't have tuples as part of the SDK ?
> >>> To the best of my knowledge all currently supported (OSS) runners:
> Spark,
> >>> Flink, Apex provide a Tuple abstraction and I was wondering if Beam
> >> should
> >>> too ?
> >>>
> >>> Consider KV for example; it is a special ("*keyed*" by the first field)
> >>> implementation Tuple2.
> >>> While KV's importance is far more than being a Tuple2, I'm wondering if
> >> the
> >>> SDK would benefit from a proper TupleX support ?
> >>>
> >>> Thanks,
> >>> Amit
> >>>
> >>
> >> --
> >> Jean-Baptiste Onofré
> >> jbono...@apache.org
> >> http://blog.nanthrax.net
> >> Talend - http://www.talend.com
> >>
>
