Hi Xuefu,
If there is only one instance per type, then what's the "name" used for?
Could we remove it and only keep "type" or "kind" to identify modules?
Best,
Jark
On Thu, 10 Oct 2019 at 11:21, Xuefu Z wrote:
> Jark has a good point. However, I think validation logic can put in place
> to
Jingsong Lee created FLINK-14361:
Summary: Decorrelate subQuery fail when multi correlate in project
Key: FLINK-14361
URL: https://issues.apache.org/jira/browse/FLINK-14361
Project: Flink
+1
Thanks,
Jark
On Wed, 9 Oct 2019 at 01:03, Xuefu Z wrote:
> +1
>
> On Tue, Oct 8, 2019 at 7:00 AM Aljoscha Krettek
> wrote:
>
> > +1
> >
> > > On 8. Oct 2019, at 15:35, Timo Walther wrote:
> > >
> > > +1
> > >
> > > Thanks for driving these efforts,
> > > Timo
> > >
> > > On 07.10.19
Thanks for your explanation Kostas.
I agree that Clients are independent from the Executors. From
your text I wonder one thing that whether Executor#execute
returns a cluster client or a job client? As discussed previously
I think conceptually it is a job client?
Best,
tison.
Kostas Kloudas
Hi Tison,
I would say that as a first step, and until we see that the interfaces
we introduce cover all intended purposes, we keep the Executors
non-public.
>From the previous discussion, I think that in general the Clients are
independent from the Executors, as the Executors simply use the
Zhu Zhu created FLINK-14362:
---
Summary: Change DefaultSchedulingResultPartition to return correct
partition state
Key: FLINK-14362
URL: https://issues.apache.org/jira/browse/FLINK-14362
Project: Flink
Thanks for start this survey, Piotr.
We have benefitted from credit-based flow control a lot. I can't figure out
a reason to use non credit-based model.
I think we have kept the older code paths long enough (1.5 -> 1.9). That's
a big burden to maintain. Especially there are a lot duplicated codes
Yes, it is a JobClient.
Cheers,
Kostas
On Thu, Oct 10, 2019 at 11:26 AM Zili Chen wrote:
>
> Thanks for your explanation Kostas.
>
> I agree that Clients are independent from the Executors. From
> your text I wonder one thing that whether Executor#execute
> returns a cluster client or a job
Shen Yinjie created FLINK-14360:
---
Summary: Flink on yarn should support obtain delegation tokens of
multi hdfs namespaces
Key: FLINK-14360
URL: https://issues.apache.org/jira/browse/FLINK-14360
Hi all,
Given the current state of this voting thread, FLIP-73 is accepted.
I will update the wiki to reflect that the result of the vote.
Thanks a lot for your votes,
Kostas
On Sun, Oct 6, 2019 at 10:36 AM Aljoscha Krettek wrote:
>
> +1
>
> > On 4. Oct 2019, at 18:12, Thomas Weise wrote:
> >
+1
Best,
Jingsong Lee
On Thu, Oct 10, 2019 at 3:38 PM Jark Wu wrote:
> +1
>
> Thanks,
> Jark
>
> On Wed, 9 Oct 2019 at 01:03, Xuefu Z wrote:
>
> > +1
> >
> > On Tue, Oct 8, 2019 at 7:00 AM Aljoscha Krettek
> > wrote:
> >
> > > +1
> > >
> > > > On 8. Oct 2019, at 15:35, Timo Walther wrote:
>
Zhu Zhu created FLINK-14363:
---
Summary: No need to cancel vertex when its version is outdated in
scheduling (SchedulerNG)
Key: FLINK-14363
URL: https://issues.apache.org/jira/browse/FLINK-14363
Project:
Hi Arvid,
Very thanks for bring up the discussion! From our side unable to
finish the checkpoint is commonly met for online jobs, therefore +1 from my
side to implement this.
A tiny issue of the FLIP is that the Discussion Thread URL attached
seems to be not right.
I also heard from other companies that upgrading to Python 3 is in
progress for data teams.
+1 for simplifying the code base with option 1).
Thanks,
Timo
On 08.10.19 16:34, Dian Fu wrote:
Hi everyone,
I would like to propose to drop Python 2 support(Currently Python 2.7, 3.5,
3.6, 3.7 are
Hi Jark,
restricting one module instance per kind sounds good to me. Modules can
implement hashCode/equals and we can perform the check you metioned. The
equals() method can determine what "same kind" means.
Correct me if I'm wrong, but we wanted to perform a big properties
rework soonish
Hi everyone,
thanks for the great discussion with a good outcome.
I have one last comment about:
void createTemporaryFunction(String path, UserDefinedFunction function);
We should encourage users to register a class instead of an instance. We
should enforce a default constructor in the
The purpose of ConnectTableDescriptor was to have a programmatic way of
expressing `CREATE TABLE` with JavaDocs and IDE support. But I agree
that it needs some rework in the future, once we have finalized the DDL
to ensure that both concepts are in sync.
Regards,
Timo
On 10.10.19 16:08,
Hi Jark,
we had a long offline discussion yesterday where we considered all
options again. The reasons why we decided for the updated design that
Bowen suggested:
- Both Dawid and Xuefu argued that in the old design "kind" has binary
meanings. I agree here.
- Compared to other SQL concepts
Hi Timo,
Thanks for the explanation, it makes sense to me.
So at least, we can have a validation to restrict one module instance per
type in the first version.
Regarding to "type" vs "kind", could we use "datatype" keyword to refer
data types exclusively in the future?
This can avoid the
Regarding to ConnectTableDescriptor, if in the end it becomes a builder
of CatalogTable, I would be ok with that. But it doesn't look like a builder
now, it's more like another form of TableSource/TableSink.
Best,
Kurt
On Thu, Oct 10, 2019 at 3:44 PM Timo Walther wrote:
> Hi everyone,
>
>
Thanks for the clarification Timo, that's sounds good to me. Let's continue
to discuss other things.
Best,
Kurt
On Thu, Oct 10, 2019 at 4:14 PM Timo Walther wrote:
> The purpose of ConnectTableDescriptor was to have a programmatic way of
> expressing `CREATE TABLE` with JavaDocs and IDE
Thanks for the comments.
@Timo I think your suggestion makes sense. I changed the signature to
void createTemporaryFunction(String path, Class
functionClass);
This will mean that after we make QueryOperations string serializable
and we expose the type inference in functions we will have only a
I think we should introduce a separate interface for the ResourceManager so
that it can list and delete global result partitions from the shuffle
service implementation. As long as the JM and RM run in the same process,
this interface could be implemented by the ShuffleMaster implementations.
Regarding to createTemporaryFunction, could we just keep both choices? I
agree
we should encourage users to use the class, and it's the only choice when
user
using DDL. But for some Table API & SQL programs, I think it's actually
more nature
to use an object instead of use the classes. But this
Hi Terry
Flink has a code-style and quality guide when contributes code[1], this might
not be directly what you want but hope could help a bit.
As more and more big data system recommend high level and declarative API such
as SQL and Table API [2], I think GOF design patterns might not play an
Hi Arvid
+1 for this future which has been hoped for a long time. End-to-end exactly
once job could benefit from quicker checkpoint completion.
Best
Yun Tang
From: Yun Gao
Sent: Thursday, October 10, 2019 18:39
To: dev
Subject: Re: [DISCUSS] FLIP-76:
Jingsong Lee created FLINK-14364:
Summary: Allow comments fail when not ignore parse errors in
CsvRowDeserializationSchema
Key: FLINK-14364
URL: https://issues.apache.org/jira/browse/FLINK-14364
Hi, Timo
Regarding to createTemporaryFunction, I agree with Kurt, we should
encourage the class way, but should keep the instance way.
The reason is that this is an important feature to support parameterize
function as you said, but this can't be addressed by global job parameters
and open()
+1. The interface looks fine to me.
Regards,
Xiaogang
Zili Chen 于2019年10月9日周三 下午2:36写道：
> Given the ongoing FlinkForward Berlin event, I'm going to extend
> this vote thread with a bit of period, said until Oct. 11th(Friday).
>
> Best,
> tison.
>
>
> Zili Chen 于2019年10月7日周一 下午4:15写道：
>
> > Hi
Hi Timo,
I agree that we are going to rework properties soon.
But we may come up with a better name or a better way than "kind" when the
proposal is started and more people involved.
On the other hand, reworking properties should be a compatible way.
So I think it's fine to use "type" for now
30 matches
Mail list logo
