Congratulations, Zhu Zhu!
On Fri, Dec 13, 2019 at 10:37 AM Peter Huang
wrote:
> Congratulations!:)
>
> On Fri, Dec 13, 2019 at 9:45 AM Piotr Nowojski
> wrote:
>
> > Congratulations! :)
> >
> > > On 13 Dec 2019, at 18:05, Fabian Hueske wrote:
> > >
> > > Congrats Zhu Zhu and welcome on board!
Thanks all for the healthy discussions. I'd just like to point out a light
difference between standard and standard compatibility. Most of DB vendors
meant the latter when they claim following a sql standard. However, it
doesn't mean they don't have any syntax beyond the standard grammar.
Hi Dawid,
Thanks for initiating this discussion. I understand the problem you
described, but the solution might not work as having an apache.org email
address doesn't necessary mean it's from a Flink committer. This certainly
applies to me.
It probably helps for the voters to identify themselves
+1 (non-binding)
On Wed, Nov 20, 2019 at 4:40 AM Kurt Young wrote:
> +1 (binding)
>
> Best,
> Kurt
>
>
> On Wed, Nov 20, 2019 at 6:56 PM Aljoscha Krettek
> wrote:
>
> > +1 (binding)
> >
> > Best,
> > Aljoscha
> >
> > > On 20. Nov 2019, at 11:36, Jingsong Li wrote:
> > >
> > > +1 (non-binding)
+1
On Fri, Nov 22, 2019 at 5:31 AM Kurt Young wrote:
> +1
>
> Best,
> Kurt
>
>
> On Fri, Nov 22, 2019 at 8:51 PM Dawid Wysakowicz
> wrote:
>
> > Hi everyone,
> >
> > I would like to start a vote on FLIP-87.
> >
> > Please vote for the following design document:
> >
>
freeze (planned to be at the
> > end
> > > of
> > > > November) [2], I'm a little bit concerned about the schedule.
> > > >
> > > > [1]
> > > https://cwiki.apache.org/confluence/display/FLINK/Time-based+releases
> > > > [2]
>
Regarding the package name, etc:
statefun certainly sounds more interesting, but it's confusing in my
opinion and doesn't reflect its true nature. A letter "c" at the end may
helps as "func" is more used as a short for "function" in CS.
Thanks,
Xuefu
On Fri, Nov 8, 2019 at 3:52 AM Igal Shilman
Hi Peter,
Thanks for driving this. I'm all-in for this. However, as I read the latest
FLIP, I have a couple of questions/comments:
1. It seems that "JVM" is proposed as a language type in parallel to
python. I'm not sure that's very intuitive. JVM stands for "java virtual
machine", so the
Many congratulations, Jark!
On Fri, Nov 8, 2019 at 2:31 AM wenlong.lwl wrote:
> Congratulations Jark, well deserved!
>
>
> Best,
> Wenlong Lyu
>
> On Fri, 8 Nov 2019 at 18:22, tison wrote:
>
> > Congrats Jark!
> >
> > Best,
> > tison.
> >
> >
> > Jingsong Li 于2019年11月8日周五 下午6:08写道：
> >
> > >
+1 to the long missing feature in Flink SQL.
On Tue, Nov 5, 2019 at 6:32 AM Terry Wang wrote:
> Hi all,
>
> I would like to start the vote for FLIP-69[1] which is discussed and
> reached consensus in the discussion thread[2].
>
> The vote will be open for at least 72 hours. I'll try to close it
Congratulations, Becket!
On Mon, Oct 28, 2019 at 10:08 AM Zhu Zhu wrote:
> Congratulations Becket!
>
> Thanks,
> Zhu Zhu
>
> Peter Huang 于2019年10月29日周二 上午1:01写道：
>
> > Congratulations Becket Qin!
> >
> >
> > Best Regards
> > Peter Huang
> >
> > On Mon, Oct 28, 2019 at 9:19 AM Rong Rong wrote:
Thanks to Timo for bringing up an interesting topic.
Personally, "OPAQUE" doesn't seem very intuitive with respect to types. (It
suits pretty well to glasses, thought. :)) Anyway, could we just use
"UNKNOWN", which is more explicit and true reflects its nature?
Thanks,
Xuefu
On Fri, Oct 18,
+1 (non-biding)
On Wed, Oct 16, 2019 at 2:26 AM Timo Walther wrote:
> +1
>
> Thanks,
> Timo
>
>
> On 15.10.19 20:50, Bowen Li wrote:
> > Hi all,
> >
> > I'd like to kick off a voting thread for FLIP-68: Extend Core Table
> System
> > with Pluggable Modules [1], as we have reached consensus in
Thanks to Peter for the proposal!
I left some comments in the google doc. Besides what Bowen pointed out, I'm
unclear about how things work end to end from the document. For instance,
SQL DDL-like function definition is mentioned. I guess just having a DDL
for it doesn't explain how it's
; > > 1) Regarding to "loadModule", how about
> > > tableEnv.loadModule("xxx" [, propertiesMap]);
> > > tableEnv.unloadModule(“xxx”);
> > >
> > > This makes the API similar to SQL. IMO, instance of Module is not
> needed
> > > a
+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 10:10, Dawid Wysakowicz wrote:
> >> +1 for the FLIP.
> >>
> >> Best,
> >>
> >> Dawid
> >>
> >> On
I agree with Timo that the new table APIs need to be consistent. I'd go
further that an name (or id) is needed for module definition in YAML file.
In the current design, name is skipped and type has binary meanings.
Thanks,
Xuefu
On Fri, Oct 4, 2019 at 5:24 AM Timo Walther wrote:
> Hi
rsed queries, and have a unified result:
> > > >> >>>>>>
> > > >> >>>>>> ```
> > > >> >>>>>> class FunctionLookup {
> > > >> >>>>>>
> > > >> >>>>>&
Actually catalogs are more of system settings than of user objects that a
user might create or drop constantly. Thus, it's probably sufficient to set
up catalog information in the config file, at least for now.
Thanks,
Xuefu
On Tue, Sep 24, 2019 at 7:10 PM Terry Wang wrote:
> Thanks Bowen for
+1, LGTM
On Mon, Sep 23, 2019 at 10:26 AM Bowen Li wrote:
> Hi all,
>
> I'd like to start a vote for FLIP-68 [1], since there's no more concern in
> the discussion thread [2]
>
> The vote will be open for minimum 3 days till 5:30pm UTC, Sep 26.
>
> Thanks,
> Bowen
>
> [1]
>
>
+1. LGTM
On Tue, Sep 24, 2019 at 6:09 AM Terry Wang wrote:
> +1
>
> Best,
> Terry Wang
>
>
>
> > 在 2019年9月24日，上午10:42，Kurt Young 写道：
> >
> > +1
> >
> > Best,
> > Kurt
> >
> >
> > On Tue, Sep 24, 2019 at 2:30 AM Bowen Li wrote:
> >
> >> Hi all,
> >>
> >> I'd like to start a voting thread for
+1. I understand that the FLIP probably covers more we can do in one
release, but let's proritize and start with the basics first.
On Tue, Sep 24, 2019 at 10:42 AM Bowen Li wrote:
> +1. Thanks, Jingsong!
>
> Bowen
>
> On Tue, Sep 24, 2019 at 4:38 AM Terry Wang wrote:
>
> > +1, Overall looks
;>>>>>>> Looks like I'm the only person who is willing to +1 to #2 for now
> >>>> :-)
> >>>>>>>> But I would suggest to change the keyword from GLOBAL to
> >>>>>>>> something like BUILTIN.
> >>>>>&
REATE statement. The resolution
> behaviour is exactly the same in both options.
>
> On Thu, 19 Sep 2019, 08:17 Xuefu Z, wrote:
>
> > Hi Dawid,
> >
> > "GLOBAL" is a temporary keyword that was given to the approach. It can be
> > changed to something el
"keyword"
> >
> > Therefore my votes:
> > Option 1: -0
> > Option 2: -1 (I might change to +0 if we can come up with a better
> keyword)
> > Option 3: +1
> >
> > Best,
> > Dawid
> >
> >
> > On Thu, 19 Sep 2019, 05:12
end it
> is very similar to the keyword approach. In this case the catalog/db
> combination would be the "keyword"
>
> Therefore my votes:
> Option 1: -0
> Option 2: -1 (I might change to +0 if we can come up with a better keyword)
> Option 3: +1
>
> Best,
&g
> functions.
> >>>
> >>> Our group based on flink's sql parser module implements create function
> >>> feature, stores the parsed function metadata and schema into mysql, and
> >>> also customizes the catalog, customizes sql-client to support custom
Thanks to Tmo and Dawid for sharing thoughts.
It seems to me that there is a general consensus on having temp functions
that have no namespaces and overwrite built-in functions. (As a side note
for comparability, the current user defined functions are all temporary and
having no namespaces.)
HI Bowen,
Thank you for sharing your research summaries. The concerns you raised
about the modular approach are very valuable and practical. Here are some
of my thoughts..
1. Naming conflicts and resolution. Naming conflicts is likely, and as you
suggested, the resolution can be just based on
Looking at feature list, I don't see an item for complete the data type
support. Specifically, high precision timestamp is needed to Hive
integration, as it's so common. Missing it would damage the completeness of
our Hive effort.
Thanks,
Xuefu
On Sat, Sep 7, 2019 at 7:06 PM Xintong Song wrote:
ntax "cat::function". I think it's better to stick to a
> standard or at least other proved solutions from other systems.
>
> Best,
>
> Dawid
> On 05/09/2019 10:12, Xuefu Z wrote:
>
> Hi David,
>
> Thanks for sharing your thoughts and request for clarifications.
Thanks to Dawid for starting the discussion and writeup. It looks pretty
good to me except that I'm a little concerned about the object reference
and string parsing in the code, which seems to an anti-pattern to OOP. Have
we considered using ObjectIdenitifier with optional catalog and db parts,
+ func) - this is still under discussion, if we want that in the
> other
> focal point
> 5. temporary functions (3-part path)
> 6. 3-part catalog functions a.k.a. user functions
>
> I would be really grateful if you could explain me those questions, thanks.
>
&g
ttps://www.postgresql.org/docs/10/extend-extensions.html
> > [2] https://prestodb.github.io/docs/current/develop/functions.html
> >
> >
> > On 04.09.19 13:44, Jark Wu wrote:
> >
> > Hi all,
> >
> > Regarding #1 temp function <> built-in function
n, I'm afraid we will
> have compatibility issues in the future.
> Say users register a user defined function named "explode" in 1.9, and we
> support a built-in "explode" function in 1.10.
> Then the user's jobs which call the registered "explode" func
in functions, and I have presented my reasons. Just in case if we
> > cannot reach an agreement, I propose forbid users registering temp
> > functions in the same name as a built-in function, like MySQL's approach,
> > for the moment. It won't have any performance concern, s
>From what I have seen, there are a couple of focal disagreements:
1. Resolution order: temp function --> flink built-in function --> catalog
function vs flink built-in function --> temp function -> catalog function.
2. "External" built-in functions: how to treat built-in functions in
external
nStreamingMode()
> .withBuiltInCatalogName("ca1")
> .withBuiltInDatabaseName("db1")
> .build());
>
>
> As Dawid said, if I want to store in my custom catalog, I can call
> catalog.createTable or using DDL.
>
> Thanks,
> SImon
>
> On
Hi Simon,
Thanks for reporting the problem. There is some rough edges around catalog
API and table environments, and we are improving post 1.9 release.
Nevertheless, tableEnv.registerCatalog() is just to put a new catalog in
Flink's CatalogManager, It doens't change the default catalog/database
nated with the
> > > release manager. This doesn’t mean that your feature will not make it
> to
> > > the given release, but just inform the release manager, discuss it and
> > make
> > > an informed decision. Even for this release, there were examples were
>
.1008284.n3.nabble.com/ANNOUNCE-Feature-freeze-for-Apache-Flink-1-9-0-release-tp29751.html
> > [2]
> >
> >
> http://apache-flink-mailing-list-archive.1008284.n3.nabble.com/DISCUSS-Features-for-Apache-Flink-1-9-0-td28701.html
> >
> > Am 08.08.19 um 15:43 schrieb Xuef
Hi all,
I understand the merged PR is a feature, but it's something we had planned
and requested for a long time. In fact, at Hive connector side, we have
done a lot of work (supporting hive udf). Without this PR, all those work
would be wasted and Hive feature itself in 1.9 would also be close
Congratulations， Hequn！
On Wed, Aug 7, 2019 at 11:08 AM Yun Tang wrote:
> Congratulations Hequn.
>
> Best
> Yun Tang
>
> From: Rong Rong
> Sent: Thursday, August 8, 2019 0:41
> Cc: dev ; user
> Subject: Re: [ANNOUNCE] Hequn becomes a Flink committer
>
>
I favored #3 if that wasn't obvious.
Usability issue with #2 makes Hive too hard to use. #3 keeps the old
behavior for existing users who don't have Hive and thus there is only one,
in-memory catalog. If a user does register Hive, he/she understands that
there are multiple catalogs and that
Congratulations, Kurt!
On Tue, Jul 23, 2019 at 7:48 AM Fabian Hueske wrote:
> Congrats Kurt!
>
> Cheers, Fabian
>
> Am Di., 23. Juli 2019 um 16:42 Uhr schrieb Rong Rong >:
>
> > Congratulations Kurt!!
> >
> > --
> > Rong
> >
> > On Tue, Jul 23, 2019 at 7:31 AM zhijiang > .invalid>
> > wrote:
Congratulations, Zhijiang!
On Mon, Jul 22, 2019 at 7:42 AM Bo WANG wrote:
> Congratulations Zhijiang!
>
>
> Best,
>
> Bo WANG
>
>
> On Mon, Jul 22, 2019 at 10:12 PM Robert Metzger
> wrote:
>
> > Hey all,
> >
> > We've added another committer to the Flink project: Zhijiang Wang.
> >
> >
Congratulation, Becket! At least you're able to assign JIRAs now!
On Thu, Jul 18, 2019 at 8:22 AM Rong Rong wrote:
> Congratulations Becket!
>
> --
> Rong
>
> On Thu, Jul 18, 2019 at 7:05 AM Xingcan Cui wrote:
>
> > Congrats Becket!
> >
> > Best,
> > Xingcan
> >
> > On Thu, Jul 18, 2019, 07:17
The idea seems interesting, but I'm wondering if we have considered
publishing .tz file hosted somewhere in Flink site with a link in the doc.
This might avoid the "overkill" of introducing a repo, which is main used
for version control in development cycles. On the other hand, a docker
setup,
Congratulations, Rong!
On Thu, Jul 11, 2019 at 10:59 AM Bowen Li wrote:
> Congrats, Rong!
>
>
> On Thu, Jul 11, 2019 at 10:48 AM Oytun Tez wrote:
>
> > Congratulations Rong!
> >
> > ---
> > Oytun Tez
> >
> > *M O T A W O R D*
> > The World's Fastest Human Translation Platform.
> >
49 matches
Mail list logo
