Hi all,
I hereby announce the FLIP has passed with 6 +1 votes, 4 binding (Dawid,
Timo, Aljoscha, Jark) and 2 non-binding (Xuefu, Jingsong).
Thanks for your review and participation!
On Thu, Oct 10, 2019 at 1:08 AM Jingsong Li wrote:
> +1
>
> Best,
> Jingsong Lee
>
> On Thu, Oct 10, 2019 at
+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:
>
+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
+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
+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 07/10/2019 08:45, Bowen Li wrote:
>>> Hi all,
>>>
>>> I'd like to start a new voting
+1
Thanks for driving these efforts,
Timo
On 07.10.19 10:10, Dawid Wysakowicz wrote:
+1 for the FLIP.
Best,
Dawid
On 07/10/2019 08:45, Bowen Li wrote:
Hi all,
I'd like to start a new voting thread for FLIP-57 [1] on its latest status
despite [2], and we've reached consensus in [2] and
+1 for the FLIP.
Best,
Dawid
On 07/10/2019 08:45, Bowen Li wrote:
> Hi all,
>
> I'd like to start a new voting thread for FLIP-57 [1] on its latest status
> despite [2], and we've reached consensus in [2] and [3].
>
> This voting will be open for minimum 3 days till 6:45am UTC, Oct 10.
>
>
Hi all,
I'd like to start a new voting thread for FLIP-57 [1] on its latest status
despite [2], and we've reached consensus in [2] and [3].
This voting will be open for minimum 3 days till 6:45am UTC, Oct 10.
Thanks,
Bowen
[1]
Hi Aljoscha, Timo
Thanks for the reminder. I've update the details in FLIP wiki, and will
kick off a voting thread.
On Fri, Oct 4, 2019 at 1:51 PM Timo Walther wrote:
> Hi,
>
> I agree with Aljoscha. It is not transparent to me which votes are
> binding to the current status of the FLIP.
>
>
Hi,
I agree with Aljoscha. It is not transparent to me which votes are
binding to the current status of the FLIP.
Some other minor comments from my side:
- We don't need to deprecate methods in FunctionCatalog. This class is
internal. We can simply change the method signatures.
- `String
Hi,
I see there was quite some discussion and changes on the FLIP after this VOTE
was started. I would suggest to start a new voting thread on the current state
of the FLIP (keeping in mind that a FLIP vote needs at least three
committer/PMC votes).
For the future, we should probably keep
I'm glad to announce that the community has accepted the design of FLIP-57,
and we are moving forward to implementing it.
Thanks everyone!
On Wed, Oct 2, 2019 at 11:01 AM Bowen Li wrote:
> Introducing a new term "path" to APIs like
> "getShortPath(Identifier)/getLongPath(Identifier)" would be
Introducing a new term "path" to APIs like
"getShortPath(Identifier)/getLongPath(Identifier)" would be confusing to
users, thus I feel "getSimpleName/getIdentifier" is fine.
To summarize the discussion result.
- categorize functions into 2 dimensions - system v.s. catalog, non-temp
v.s.
Hi,
I very much agree with Xuefu's summary of the two points, especially on
the "functionIdentifier doesn't need to reflect the categories".
For the factory methods I think methods of should be enough:
// for temporary/non-temporary system function
public FunctionIdentifier of(String
Here are some of my thoughts on the minor debates above:
1. +1 for 4 categories of functions. They are categorized along two
dimensions of binary values: X: *temporary* vs non-temporary (persistent);
Y: *system* vs non-system (so said catalog).
2. In my opinion, class functionIdentifier doesn't
Hi Dawid,
Thanks for bringing the suggestions up. I was prototyping yesterday and
found out those places exactly as what you suggested.
For CallExpression and UnresolvedCallExpression, I've added them to
FLIP-57. We will replace ObjectIdentifier with FunctionIdentifier and mark
that as a
Thanks for the summary Bowen!
Looks good to me.
Cheers,
Fabian
Am Mo., 30. Sept. 2019 um 23:24 Uhr schrieb Bowen Li :
> Hi all,
>
> I've updated the FLIP wiki with the following changes:
>
> - Lifespan of temp functions are not tied to those of catalogs and
> databases. Users can create temp
Hi,
I think we're really close to a very good design for the functions.
Thank you to all involved in the discussion and especially Bowen for
driving the FLIP.
The last part I'm missing in the FLIP is a bit more elaborate
description of the FunctionIdentifier. I gave it a bit more thought and
Hi all,
I've updated the FLIP wiki with the following changes:
- Lifespan of temp functions are not tied to those of catalogs and
databases. Users can create temp functions even though catalogs/dbs in
their fully qualified names don't even exist.
- some new SQL commands
- "SHOW FUNCTIONS" -
Hi,
I think above are some valid points, and we can adopt the suggestions.
To elaborate a bit on the new SQL syntax, it would imply that, unlike "SHOW
FUNCTION" which only return function names, "SHOW ALL [TEMPORARY]
FUNCTIONS" would return functions' fully qualified names with catalog and
db
Hi all,
I support Fabian's arguments. In my opinion, temporary objects should
just be an additional layer on top of the regular catalog/database
lookup logic. Thus, a temporary table or function has always highest
precedence and should be stable within the local session. Otherwise it
could
Hi all,
Sorry for the late reply.
I think it might lead to confusing situations if temporary functions (or
any temporary db objects for that matter) are bound to the life cycle of an
(external) db/catalog.
Imaging a situation where you create a temp function in a db in an external
catalog and
@Dawid, do you have any other concerns? If not, I hope we can close the
voting.
On Thu, Sep 26, 2019 at 8:14 PM Rui Li wrote:
> I'm not sure how much benefit #1 can bring us. If users just want to try
> out temporary functions, they can create temporary system functions which
> don't require a
I'm not sure how much benefit #1 can bring us. If users just want to try
out temporary functions, they can create temporary system functions which
don't require a catalog/DB. IIUC, the main reason why we allow temporary
catalog function is to let users override permanent catalog functions.
Re 1) As described in the FLIP, a temp function lookup will first make sure
the db exists. If the db doesn't exist, a lazy drop is triggered to remove
that temp function.
I agree Hive doesn't handle it consistently, and we are not copying Hive.
IMHO, allowing registering temp functions in
Ad. 1
I wouldn't say it is hacky.
Moreover, how do you want ensure that the dB always exists when a temporary
object is used?( in this particular case function). Do you want to query
for the database existence whenever e.g a temporary function is used? I
think important aspect here is that the
Sorry, I missed some parts of the solution. The complete alternative is the
following, basically having separate APIs in FunctionLookup for ambiguous
and precise function lookup since planner is able to tell which API to call
with parsed queries, and have a unified result:
```
class
Hi Dawid,
Re 1): I agree making it easy for users to run experiments is important.
However, I'm not sure allowing users to register temp functions in
nonexistent catalog/db is the optimal way. It seems a bit hacky, and breaks
the current contract between Flink and users that catalog/db must be
Hi,
I really like the flip and think it clarifies important aspects of the
system.
I have two, I hope small suggestions, which will not take much time to
agree on.
1. Could we follow the MySQL approach in regards to the existence of cat/db
for temporary functions? That means not to check it, so
+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
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 FLIP-57 [1], which we've reached
>> consensus in [2].
>>
>> This voting will be open for
+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 FLIP-57 [1], which we've reached
> consensus in [2].
>
> This voting will be open for minimum 3 days till 6:30pm UTC, Sep 26.
>
> Thanks,
> Bowen
>
> [1]
>
>
Hi all,
I'd like to start a voting thread for FLIP-57 [1], which we've reached
consensus in [2].
This voting will be open for minimum 3 days till 6:30pm UTC, Sep 26.
Thanks,
Bowen
[1]
https://cwiki.apache.org/confluence/display/FLINK/FLIP-57%3A+Rework+FunctionCatalog
[2]
33 matches
Mail list logo
