On Tue, Dec 13, 2016 at 9:02 AM, Jean-Baptiste Onofré <[email protected]> wrote: > Hi Robert, > > Agree, however which one the user would use ? Create his own one ?
Whichever suits their needs best, which could include his or her own. > Today, I think Beam is heavily flexible in term of data format (which is > great), but the trade off is that the end-users have to write lot of > boilerplate code (just to convert from one type to another). > > So, basically, the purpose of a Beam Tuple is to have something provided out > of box: if the user wants to use another tuple, that's fine. > Generally speaking, the discussion about data format extension is about to > simplify the way for users to manipulate popular data formats. If I understand correctly, the proposal is to pick (or write) a Tuple API and bless it by shipping it with the SDK along with beam-specific helper code. I'd be helpful to see concretely how large of a savings this would be to a user, and whether that's worth the cost. > On 12/13/2016 05:56 PM, Robert Bradshaw wrote: >> >> 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) < >> [email protected]> 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 <[email protected]> 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é <[email protected]> >>>> 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é >>>>> [email protected] >>>>> http://blog.nanthrax.net >>>>> Talend - http://www.talend.com >>>>> >>> >> > > -- > Jean-Baptiste Onofré > [email protected] > http://blog.nanthrax.net > Talend - http://www.talend.com
