Zakelly Lan created FLINK-35812:
---
Summary: Move tuple interfaces to flink-core-api
Key: FLINK-35812
URL: https://issues.apache.org/jira/browse/FLINK-35812
Project: Flink
Issue Type
Zhipeng Zhang created FLINK-32292:
-
Summary: TableUtils.getRowTypeInfo fails to get type information
of Tuple
Key: FLINK-32292
URL: https://issues.apache.org/jira/browse/FLINK-32292
Project: Flink
James Schulte created FLINK-26529:
-
Summary: PyFlink 'tuple' object has no attribute '_values'
Key: FLINK-26529
URL: https://issues.apache.org/jira/browse/FLINK-26529
Project: F
Gyula Fora created FLINK-17420:
--
Summary: Cannot alias Tuple and Row fields when converting
DataStream to Table
Key: FLINK-17420
URL: https://issues.apache.org/jira/browse/FLINK-17420
Project: Flink
Aljoscha Krettek created FLINK-17074:
Summary: Deprecate DataStream.keyBy() that use tuple/expression
keys
Key: FLINK-17074
URL: https://issues.apache.org/jira/browse/FLINK-17074
Project: Flink
Nico Kruber created FLINK-9435:
--
Summary: Remove per-key selection Tuple instantiation via
reflection in KeySelectorUtil#ComparableKeySelector
Key: FLINK-9435
URL: https://issues.apache.org/jira/browse/FLINK-9435
Timo Walther created FLINK-8386:
---
Summary: Scala API cannot create type information for Tuple
interface
Key: FLINK-8386
URL: https://issues.apache.org/jira/browse/FLINK-8386
Project: Flink
Jark Wu created FLINK-6888:
--
Summary: Can not determine TypeInformation of ACC type of
AggregateFunction when ACC is a Scala case/tuple class
Key: FLINK-6888
URL: https://issues.apache.org/jira/browse/FLINK-6888
Luke Hutchison created FLINK-6115:
-
Summary: Need more helpful error message when trying to serialize
a tuple with a null field
Key: FLINK-6115
URL: https://issues.apache.org/jira/browse/FLINK-6115
Yakov Goldberg created FLINK-4795:
-
Summary: CsvStringify crashes in case of tuple in tuple, t.e.
("a", True, (1,5))
Key: FLINK-4795
URL: https://issues.apache.org/jira/browse/FLINK-4795
Greg Hogan created FLINK-4734:
-
Summary: Remove use of Tuple setField for fixed position
Key: FLINK-4734
URL: https://issues.apache.org/jira/browse/FLINK-4734
Project: Flink
Issue Type
Aljoscha Krettek created FLINK-4238:
---
Summary: Only allow/require query for Tuple Stream in CassandraSink
Key: FLINK-4238
URL: https://issues.apache.org/jira/browse/FLINK-4238
Project: Flink
be expected from hand written
> >> > > serializers.
> >> > > > >
> >> > > > > Best regards,
> >> > > > > Gábor
> >> > > > >
> >> > > > > On 8 March 2016 at 10:47, Stephan Ewen
> wrote:
>
wrote:
>> > > > >
>> > > > > > Ah, very good, that makes sense!
>> > > > > >
>> > > > > > I would guess that this performance difference could probably be
>> > seen
>> > > > at
>> > > > > > various points wher
ance difference could probably be
> > seen
> > > > at
> > > > > > various points where generic serializers and comparators are used
> > > (also
> > > > > for
> > > > > > Comparable, Writable) or
> > > > >
.
> > > > >
> > > > > I guess creating more specialized serializers would solve some of
> > these
> > > > > problems, like in your IntValue vs LongValue case.
> > > > >
> > > > > The best way to solve that would probably be through code
> g
izer delegates to a sequence of other
> > > TypeSerializers.
> > > >
> > > > I guess creating more specialized serializers would solve some of
> these
> > > > problems, like in your IntValue vs LongValue case.
> > > >
> > > > The best wa
se.
> > >
> > > The best way to solve that would probably be through code generation in
> > the
> > > serializers. That has actually been my wish for quite a while.
> > > If you are also into these kinds of low-level performance topics, we
> > could
> &
s. That has actually been my wish for quite a while.
> > If you are also into these kinds of low-level performance topics, we
> could
> > start a discussion on that.
> >
> > Greetings,
> > Stephan
> >
> >
> > On Mon, Mar 7, 2016 at 11:25 PM, Greg
n
>
>
> On Mon, Mar 7, 2016 at 11:25 PM, Greg Hogan wrote:
>
> > The issue is not with the Tuple hierarchy (running Gelly examples had no
> > effect on runtime, and as you note there aren't any subclass overrides)
> but
> > with CopyableValue. I had been
performance topics, we could
start a discussion on that.
Greetings,
Stephan
On Mon, Mar 7, 2016 at 11:25 PM, Greg Hogan wrote:
> The issue is not with the Tuple hierarchy (running Gelly examples had no
> effect on runtime, and as you note there aren't any subclass overrides)
The issue is not with the Tuple hierarchy (running Gelly examples had no
effect on runtime, and as you note there aren't any subclass overrides) but
with CopyableValue. I had been using IntValue exclusively but had switched
to using LongValue for graph generation. CopyableValueComparato
Hi Greg!
Sounds very interesting.
Do you have a hunch what "virtual" Tuple methods are being used that become
less jit-able? In many cases, tuples use only field accesses (like
"vakle.f1") in the user functions.
I have to dig into the serializers, to see if they could s
execute a separate jar which executes
essentially the same algorithm but using Gelly's Edge (which subclasses
Tuple3 but does not add any extra fields) and now both the Tuple and Edge
algorithms take twice as long.
Has this been previously discussed? If not I can work up a demonstrat
Nick Dimiduk created FLINK-3119:
---
Summary: Remove dependency on Tuple from HadoopOutputFormat
Key: FLINK-3119
URL: https://issues.apache.org/jira/browse/FLINK-3119
Project: Flink
Issue Type
Matthias J. Sax created FLINK-2721:
--
Summary: Add Tuple meta information
Key: FLINK-2721
URL: https://issues.apache.org/jira/browse/FLINK-2721
Project: Flink
Issue Type: New Feature
t;> creates an infinite number of tuples and then counts them, right?
>>>>
>>>> The problem with serialization as i understand it is that the receiver
>>>> can't tell how many Tuple0 are sent, since you never actually read any
>>>> data
nd it is that the receiver
can't tell how many Tuple0 are sent, since you never actually read any
data when deserializing a tuple. it's even more likely that it's not
even attempted.
As such, I'd be curious to see what happens when you create a batch job
that with a limited numbe
Tuple0 are sent, since you never actually read any
>> data when deserializing a tuple. it's even more likely that it's not
>> even attempted.
>>
>> As such, I'd be curious to see what happens when you create a batch job
>> that with a limited number of st
nite number of tuples and then counts them, right?
>
> The problem with serialization as i understand it is that the receiver
> can't tell how many Tuple0 are sent, since you never actually read any
> data when deserializing a tuple. it's even more likely that it's not
nite number of tuples and then counts them, right?
>
> The problem with serialization as i understand it is that the receiver
> can't tell how many Tuple0 are sent, since you never actually read any
> data when deserializing a tuple. it's even more likely that it's not
nite number of tuples and then counts them, right?
>
> The problem with serialization as i understand it is that the receiver
> can't tell how many Tuple0 are sent, since you never actually read any
> data when deserializing a tuple. it's even more likely that it's not
sent, since you never actually read any
> data when deserializing a tuple. it's even more likely that it's not
> even attempted.
>
> As such, I'd be curious to see what happens when you create a batch job
> that with a limited number of starting tuples.
>
> On 04.0
data when deserializing a tuple. it's even more likely that it's not
even attempted.
As such, I'd be curious to see what happens when you create a batch job
that with a limited number of starting tuples.
On 04.08.2015 13:08, Matthias J. Sax wrote:
Hi,
I just opened a PR for
Sax wrote:
> Thanks for the advice about Tuple0.
>
> I personally don't see any advantage in having "flink-tuple" project. Do
> I miss anything about it? Furthermore, I am not sure if it is a good
> idea the have too many too small projects.
>
>
> On 08/03/2015 1
e> wrote:
> Thanks for the advice about Tuple0.
>
> I personally don't see any advantage in having "flink-tuple" project. Do
> I miss anything about it? Furthermore, I am not sure if it is a good
> idea the have too many too small projects.
>
>
> On 08/03/2015 1
Thanks for the advice about Tuple0.
I personally don't see any advantage in having "flink-tuple" project. Do
I miss anything about it? Furthermore, I am not sure if it is a good
idea the have too many too small projects.
On 08/03/2015 12:48 AM, Stephan Ewen wrote:
> Tuple0
Tuple0 would need special serialization and comparator logic. If that is
given, I see no reason not to support it.
There is BTW, the request to create a dedicated "flink-tuple" project, that
only contains the tuple classes. Any opinions on that?
On Mon, Aug 3, 2015 at 12:45 AM, Matth
lly good idea to start a discussion about this.
>
> So the general idea behind Tuple0 was this:
>
> The Python API maps python tuples to flink tuples. Python can have empty
> tuples, so i thought "well duh, let's make a Tuple0 class!". What i did
> not wanna d
is create some non-Tuple object to represent empty tuples,
I'd rather have them treated the same, because it's less work and
creates simpler code.
When transferring the plan to java, certain parameters for operations
are tuples, which can be empty aswell.
This is where the Tuple0 class
, Stephan Ewen wrote:
> I think a Tuple0 cannot be implemented like the current tuples, at least
> with respect to runtime serialization.
>
> The system makes the assumption that it makes progress in consuming bytes
> when deserializing values. If a Tuple= never consumes data from the byte
I think a Tuple0 cannot be implemented like the current tuples, at least
with respect to runtime serialization.
The system makes the assumption that it makes progress in consuming bytes
when deserializing values. If a Tuple= never consumes data from the byte
stream, this assumption is broken. It
I just double checked. Scala does not have type Tuple0. IMHO, it would
be best to remove Tuple0 for consistency. Having Tuple types is for
consistency reason with Scala in the first place, right? Please give
feedback.
-Matthias
On 08/01/2015 01:04 PM, Matthias J. Sax wrote:
> I see.
>
yes, if it is present in the core flink files it must work just as any
tuple in flink.
removing is not an option though; but moving is. The Python API uses it
(that's the reason Tuple0 was added in the first place).
On 01.08.2015 13:04, Matthias J. Sax wrote:
I see.
I think that it
t;> there's no specific reason. it was added fairly recently by me (mid of
>> april), and you're most likely the second person to use it.
>>
>> i didn't integrate into all our tuple related stuff because, well, i
>> never thought anyone would actually ne
it.
i didn't integrate into all our tuple related stuff because, well, i
never thought anyone would actually need it, so i saved myself the
trouble.
Hi,
is there any specific reason, why Tuple.getTupleClass(int arity) does
not support arity zero? There is a class Tuple0, but it ca
there's no specific reason. it was added fairly recently by me (mid of
april), and you're most likely the second person to use it.
i didn't integrate into all our tuple related stuff because, well, i
never thought anyone would actually need it, so i saved myself the trouble.
Hi,
is there any specific reason, why Tuple.getTupleClass(int arity) does
not support arity zero? There is a class Tuple0, but it cannot be
generator by Tuple.getTupleClass(...). Is it a missing feature (I would
like to have it).
-Matthias
signature.asc
Description: OpenPGP digital signature
Gabor Gevay created FLINK-2447:
--
Summary: TypeExtractor returns wrong type info when a Tuple has
two fields of the same POJO type
Key: FLINK-2447
URL: https://issues.apache.org/jira/browse/FLINK-2447
Theodore Vasiloudis created FLINK-2202:
--
Summary: Calling distinct() requires tuple input
Key: FLINK-2202
URL: https://issues.apache.org/jira/browse/FLINK-2202
Project: Flink
Issue Type
I try to write as
> CSV, I get an exception:
>
> java.lang.IllegalArgumentException: requirement failed: CSV output can
> only be used with Tuple DataSets.
>
> It seems that an instance of _DataSet[scala.Tuple2[Long, Long]]_ is
> somehow considered different from an instance of_ DataSet[(Long,
> Lon
the method available in _org.apache.flink.api.scala.package. _This
works fine when I print out the result, but when I try to write as
CSV, I get an exception:
java.lang.IllegalArgumentException: requirement failed: CSV output can
only be used with Tuple DataSets.
It seems that an instance of _Data
put can
only be used with Tuple DataSets.
It seems that an instance of _DataSet[scala.Tuple2[Long, Long]]_ is
somehow considered different from an instance of_ DataSet[(Long,
Long)]_
Are there any suggestions on how to fix this problem? Note that I
cannot hardcode the conversion as the tuple size
7;),
> but you can use other classes. Create your own tuple POJO with subclasses,
> and it should work.
>
> Stephan
>
>
> On Thu, May 28, 2015 at 1:30 AM, Amit Pawar
> wrote:
>
> > Hi
> >
> > Is there a way, where I can add a custom (newly created) Tupl
Hi!
If you want to have type hierarchies (like base tuples and different
classes), you cannot use tuples (they are expected to be 'exact schema'),
but you can use other classes. Create your own tuple POJO with subclasses,
and it should work.
Stephan
On Thu, May 28, 2015 at 1:30 AM,
Hi
Is there a way, where I can add a custom (newly created) Tuple to a new
DataSet or already existing DataSet?
DataSet set = env.fromElements (myCustomTuple);
works fine, but only with same datatype in case of Tuple2 or higher.
Tuple2 creates a problem (as stated in JavaDoc it needs all
It would be an interesting addition.
Such a method cannot be done fully type safe in Java, but that might be
okay, since it is user-code internal.
On Wed, May 27, 2015 at 11:52 AM, Flavio Pompermaier
wrote:
> Sorry, to be effective the project should also take in input the target
>
Sorry, to be effective the project should also take in input the target
tuple itself :)
Tuple3 reuse = tuple.project(reuse, 0,2,5)?
On Wed, May 27, 2015 at 11:51 AM, Flavio Pompermaier
wrote:
> Hi flinkers,
>
> it happens very often to me that I have to output a reuse tuple that
>
Hi flinkers,
it happens very often to me that I have to output a reuse tuple that
basically is a subset of the data contained of the input tuple..do you
think it could be useful to add a project method to Tuple class?
So that to be able to write something like:
Tuple3 reuse = tuple.project
Fabian Hueske created FLINK-1919:
Summary: Add HCatOutputFormat for Tuple data types
Key: FLINK-1919
URL: https://issues.apache.org/jira/browse/FLINK-1919
Project: Flink
Issue Type: New
Fabian Hueske created FLINK-1906:
Summary: Add tip to work around plain Tuple return type of project
operator
Key: FLINK-1906
URL: https://issues.apache.org/jira/browse/FLINK-1906
Project: Flink
Fabian Hueske created FLINK-1490:
Summary: Incorrect local output sort for tuple position keys with
nested tuples
Key: FLINK-1490
URL: https://issues.apache.org/jira/browse/FLINK-1490
Project: Flink
62 matches
Mail list logo
