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.
> > oy...@motawor
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, once
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
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.
> >
> > Congratu
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:
>
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 fully
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
>
> Congrat
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 t
> http://apache-flink-mailing-list-archive.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
> >
&g
the release branch should be strictly coordinated 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 fo
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 a
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
>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 sys
precede Flink
> > built-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 wo
uilt-in function and can
> override built-in functions (we already support to override built-in
> function in 1.9).
> If we don't allow the same name as a built-in function, I'm afraid we will
> have compatibility issues in the future.
> Say users register a user define
be used as a
> > reference. I don't think that a user can overwrite a built-in function
> > there.
> >
> > Regards,
> > Timo
> >
> > [1] https://www.postgresql.org/docs/10/extend-extensions.html
> > [2] https://prestodb.github.io/docs/current/deve
, Sep 5, 2019 at 12:04 PM Bowen Li wrote:
> Maybe Xuefu missed my email. Please let me know what your thoughts are on
> the summary, if there's still major controversy, I can take time to
> reevaluate that part.
>
>
> On Wed, Sep 4, 2019 at 2:25 PM Xuefu Z wrote:
>
>
g functions a.k.a. "external built-in functions"
> (cat + 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
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,
esp
tely don't
> like the special syntax "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 yo
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:
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 the
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.)
Neve
f
> 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 su
ce. In the 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
>
> B
on 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,
> > Dawid
> >
> >
> > On Thu, 19 S
esides in the CREATE 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
p 19, 2019 at 4:40 PM Kurt Young
> >>> wrote:
> >>>>>>>> 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
> >>
+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 FL
+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 goo
+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]
>
> https://cwiki.apach
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 y
gt; >> >>> to
> > > >> >>>>> call
> > > >> >>>>>> with parsed queries, and have a unified result:
> > > >> >>>>>>
> > > >> >>>>>> ```
> > > >> >>
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 everyone,
+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
gt;
> > > 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
> > >
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 supporte
+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 [2
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, 201
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:
+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
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写道：
> >
> > > C
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 languag
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
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]
&
+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:
> >
> https://cwiki.apache.org/co
+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)
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
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.
Extensio
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!
>
50 matches
Mail list logo
