Stefano Bortoli created FLINK-9252:
--
Summary: OperatorChain.pushToOperators NullPointerException when
ClassCastException
Key: FLINK-9252
URL: https://issues.apache.org/jira/browse/FLINK-9252
Project
nless to expose that.
On Fri, Mar 2, 2018 at 9:37 PM Stefano Bortoli
wrote:
> Hi Timo, Renjie,
>
> What I was thinking did not include the QueryableStateTableSink, but
> rather tap in directly into the state of a streaming operator. Perhaps
> it is the same thing, but just it so
on
> such
> >>>> a QueryableStateTableSink [1] in the past but never finished it
> because
> >>>> of priority shifts. Would be great if somebody wants to
> >>>> contribute
> this
> >>>> functionality :)
> >>>>
> &g
Hi guys,
I am checking out the queriable state API, and it seems that most of the
tooling is already available. However, the queriable state is available just
for the streaming API, not at the StreamSQL API level. In principle, as the
flink-table is aware of the query semantic and data output t
Stefano Bortoli created FLINK-7371:
--
Summary: user defined aggregator assumes nr of arguments smaller
or equal than number of row fields
Key: FLINK-7371
URL: https://issues.apache.org/jira/browse/FLINK-7371
Stefano Bortoli created FLINK-7339:
--
Summary: aggregationToString fails when user defined aggregation
contains constants
Key: FLINK-7339
URL: https://issues.apache.org/jira/browse/FLINK-7339
Project
Stefano Bortoli created FLINK-7338:
--
Summary: User Defined aggregation with constants causes error
under in lowerbound over window extraction
Key: FLINK-7338
URL: https://issues.apache.org/jira/browse/FLINK-7338
Hi all,
I am playing around with the table API, and I have a doubt about temporal
operator overlaps. In particular, a test in the
scalarFunctionsTest.testOverlaps checks for false the following intervals:
testAllApis(
temporalOverlaps("2011-03-10 05:02:02".toTimestamp, 0.second,
"2
Stefano Bortoli created FLINK-6388:
--
Summary: Add support for DISTINCT into Code Generated Aggregations
Key: FLINK-6388
URL: https://issues.apache.org/jira/browse/FLINK-6388
Project: Flink
other than the intended recipient(s) is
> prohibited. If you receive this e-mail in error, please notify the sender
> by phone or email immediately and delete it!
>
>
> -Original Message-
> From: fhue...@gmail.com [mailto:fhue...@gmail.com]
> Sent: Tuesday, April 11, 2017 2:24
Hi Xingcan,
Are you using parallelism 1 for the test? procTime semantics deals with the
objects as they loaded in the operators. It could be the co-occuring
partitioned events (in the same MS time frame) are processed in parallel and
then the output is produced in different order.
I suggest y
ssing time is
somewhat arbitrary anyway.
Best, Fabian
2017-04-04 10:23 GMT+02:00 Stefano Bortoli :
> Hi guys,
>
> Based on the discussion about time management in
> https://github.com/apache/flink/pull/3641 , does it make sense to use
> nanoTime for procTime semantic aggregation
Hi guys,
Based on the discussion about time management in
https://github.com/apache/flink/pull/3641 , does it make sense to use nanoTime
for procTime semantic aggregation processing? This way we will not have the
possibility of events falling in the same "millisecond" processing bucket and
kee
Hi all,
I have completed a first implementation that works for the SQL query
SELECT a, SUM(b) OVER (PARTITION BY c ORDER BY a RANGE BETWEEN 2 PRECEDING) AS
sumB FROM MyTable
I have SUM, MAX, MIN, AVG, COUNT implemented but I could test it just on simple
queries such as the one above. Is there a
Thanks for confirming this. After the email I started working on it and things
became more clear already. I will go ahead this way.
Dr. Stefano Bortoli
Senior Research Engineer - Big Data and Semantic Technology Expert
IT R&D Division
-Original Message-
From: Fabian Hu
,
aggregate calls, parameter pointers, etc. )
Dr. Stefano Bortoli
Senior Research Engineer - Big Data and Semantic Technology Expert
IT R&D Division
HUAWEI TECHNOLOGIES Duesseldorf GmbH
European Research Center
Riesstrasse 25, 80992 München
-Original Message-
From: Fabian Hu
Stefano Bortoli created FLINK-5710:
--
Summary: Add ProcTime() function to indicate StreamSQL
Key: FLINK-5710
URL: https://issues.apache.org/jira/browse/FLINK-5710
Project: Flink
Issue Type
@flink.apache.org
Subject: Re: [jira] [Created] (FLINK-5656) Add processing time OVER ROWS
BETWEEN UNBOUNDED PRECEDING aggregation to SQL
Hi Stefano,
I can assign the issue to you if you want to.
Just drop a comment in JIRA.
Best, Fabian
2017-01-27 9:39 GMT+01:00 Stefano Bortoli :
> Hi Fab
processing time OVER ROWS
BETWEEN UNBOUNDED PRECEDING aggregation to SQL
Hi Stefano,
I can assign the issue to you if you want to.
Just drop a comment in JIRA.
Best, Fabian
2017-01-27 9:39 GMT+01:00 Stefano Bortoli :
> Hi Fabian,
>
> In the next days I will start working on this issue
Hi Fabian,
In the next days I will start working on this issue. As soon as I have a
proposal I will start sharing it for discussion.
Regards,
Dr. Stefano Bortoli
Senior Research Engineer - Big Data and Semantic Technology Expert
IT R&D Division
-Original Message-
From: Fabian Hu
Stefano Bortoli created FLINK-4909:
--
Summary: JDBC Input format cast exception management
Key: FLINK-4909
URL: https://issues.apache.org/jira/browse/FLINK-4909
Project: Flink
Issue Type
Thanks Vasia for the very clear explanation.
saluti,
Stefano
2016-05-17 14:53 GMT+02:00 Vasiliki Kalavri :
> Hi Greg,
>
> I think there is confusion between what delta means in the "delta iteration
> operator" of Flink and the "delta approximate implementation" of an
> algorithm, such as in Page
t; > wrote:
> > >
> > > > There is also InputFormat.configure() which is called before any
> split
> > > > processing happens. But I see your point about a missing close()
> method
> > > > that is called after all input spl
Of course there is one already. We'll look into the runtime context.
saluti,
Stefano
2016-04-18 9:41 GMT+02:00 Stefano Bortoli :
> Being a generic JDBC input format, I would prefer to stay with Row,
> letting the developer manage the cast according to the driver
> functionaliti
With POJO or Row? If POJO, which strategy do you suggest?
>
> Best,
> Flavio
>
> On Fri, Apr 15, 2016 at 2:06 PM, Stefano Bortoli
> wrote:
>
> > If we share the connection, then we should also be careful with the
> close()
> > implementation. I did not see change
If we share the connection, then we should also be careful with the close()
implementation. I did not see changes for this method in the PR.
saluti,
Stefano
2016-04-15 11:01 GMT+02:00 Flavio Pompermaier :
> Following your suggestions I've fixed the connection reuse in my PR at
> https://github.c
Hi Flavio,
I think this can be very handy when you have to run jobs Sqoop-like but you
need to run the process with few resources. As for Cascading, Flink could
do the heavy-lifting and make the scan of large relational databases more
robust. Of course to make it work in real world, the JDBC Input
Stefano Bortoli created FLINK-2800:
--
Summary: kryo serialization problem
Key: FLINK-2800
URL: https://issues.apache.org/jira/browse/FLINK-2800
Project: Flink
Issue Type: Bug
Stefano Bortoli created FLINK-2394:
--
Summary: HadoopOutFormat OutputCommitter is default to
FileOutputCommiter
Key: FLINK-2394
URL: https://issues.apache.org/jira/browse/FLINK-2394
Project: Flink
29 matches
Mail list logo
