Skip to content

Conversation

@bowenli86
Copy link
Member

What is the purpose of the change

  • unifies function related docs in a single dir/tab
  • add general introduction of function categories, reference mechanism, and resolution orders

Brief change log

  • renamed functions.md to builtinFunctions.md
  • unifies function related docs in a single dir/tab of docs/dev/table/functions/
  • add general introduction of function categories, reference mechanism, and resolution orders

Verifying this change

This change is a trivial rework / code cleanup without any test coverage.

Does this pull request potentially affect one of the following parts:

  • Dependencies (does it add or upgrade a dependency): (no)
  • The public API, i.e., is any changed class annotated with @Public(Evolving): (no)
  • The serializers: (no)
  • The runtime per-record code paths (performance sensitive): (no)
  • Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Yarn/Mesos, ZooKeeper: (no)
  • The S3 file system connector: (no)

Documentation

  • Does this pull request introduce a new feature? (no)
  • If yes, how is the feature documented? (docs)

@bowenli86
Copy link
Member Author

@flinkbot
Copy link
Collaborator

flinkbot commented Nov 6, 2019

Thanks a lot for your contribution to the Apache Flink project. I'm the @flinkbot. I help the community
to review your pull request. We will use this comment to track the progress of the review.

Automated Checks

Last check on commit c27cac4 (Wed Dec 04 15:07:08 UTC 2019)

✅no warnings

Mention the bot in a comment to re-run the automated checks.

Review Progress

  • ❓ 1. The [description] looks good.
  • ❓ 2. There is [consensus] that the contribution should go into to Flink.
  • ❗ 3. Needs [attention] from.
  • ❓ 4. The change fits into the overall [architecture].
  • ❓ 5. Overall code [quality] is good.

Please see the Pull Request Review Guide for a full explanation of the review process.

Details
The Bot is tracking the review progress through labels. Labels are applied according to the order of the review items. For consensus, approval by a Flink committer of PMC member is required Bot commands
The @flinkbot bot supports the following commands:

  • @flinkbot approve description to approve one or more aspects (aspects: description, consensus, architecture and quality)
  • @flinkbot approve all to approve all aspects
  • @flinkbot approve-until architecture to approve everything until architecture
  • @flinkbot attention @username1 [@username2 ..] to require somebody's attention
  • @flinkbot disapprove architecture to remove an approval you gave earlier

@flinkbot
Copy link
Collaborator

flinkbot commented Nov 7, 2019

CI report:

Bot commands The @flinkbot bot supports the following commands:
  • @flinkbot run travis re-run the last Travis build

@bowenli86
Copy link
Member Author

docs of how to register and manipulate such functions will be added later, as ddl and apis are still moving around and not finalized yet

@dawidwys
Copy link
Contributor

dawidwys commented Nov 7, 2019

@flinkbot attention @fhueske @sjwiesman

Copy link
Contributor

@sjwiesman sjwiesman left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've made a first pass of the docs.

Besides my inline comments, please change the parent nav on the pages you moved to be 'table_functions'.

nav-id: table_functions
nav-parent_id: tableapi
nav-pos: 116
is_beta: true
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why are functions beta?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

removed


There are two dimensions to classify functions in Flink.

One dimension is system (or built-in) functions v.s. catalog functions. System functions have no namespace and can be
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You say system here but named the page built in. Let's just pick one and stick with it.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

let's use "system"

Comment on lines +30 to +52
Types of Functions
------------------

There are two dimensions to classify functions in Flink.

One dimension is system (or built-in) functions v.s. catalog functions. System functions have no namespace and can be
referenced with just their names. Catalog functions belong to a catalog and database therefore they have catalog and database
namespaces, they can be referenced by either fully/partially qualified name (`catalog.db.func` or `db.func`) or just the
function name.

The other dimension is temporary functions v.s. persistent functions. Temporary functions are volatile and only live up to
lifespan of a session, they are always created by users. Persistent functions live across lifespan of sessions, they are either
provided by the system or persisted in catalogs.

The two dimensions give Flink users 4 categories of functions:

1. Temporary system functions
2. System functions
3. Temporary catalog functions
4. Catalog functions

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is conflating properties that I don't feel are related. built-in vs catalog and temporary vs persistent should be seperate sections.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I actually feel they are related to help users understand resolution order below. Maybe I should have mentioned that in resolution order, system functions always precede catalog's and temporary functions always precede persistent on its own dimension

Comment on lines +44 to +51
The two dimensions give Flink users 4 categories of functions:

1. Temporary system functions
2. System functions
3. Temporary catalog functions
4. Catalog functions
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is unnecessary and can be removed.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ditto

-->

Flink Table API & SQL empowers users to do data transformations with functions.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Add toc


In ambiguous function reference, users just specify the function's name in SQL query, e.g. `select myfunc(x) from mytable`.

This is the only supported option before Flink 1.10.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Remove, if a user is running an old version of Flink they can reference that versions docs.

Comment on lines 89 to 91
In Flink 1.10, we also redefined its function resolution order to be:

The new order is:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No need to qualify, if a user is running an old version of Flink they can reference that versions docs.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the old version actually doesn't talk about this. and this will be a disruptive change

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't understand this change well enough to be able to respond to that, however, I generally feel these kinds of changes are what release notes are for. I'd like to hear @dawidwys or @fhueske opinion and if they say it stays then +1 from me.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree with @sjwiesman. Personally I think the documentation should just describe the current state. Unless this is a disruptive change that requires users to change their code. I don't think this is the case. I

f I am wrong, and it does, I would mention the version, but also would mention what are the actions that a user must take and would change the title to something along the lines: "Migration guide/Migration"

title: "Functions"
nav-id: table_functions
nav-parent_id: tableapi
nav-pos: 116
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This renders very low down, I think functions should be higher up on the side nav.

@bowenli86
Copy link
Member Author

@sjwiesman thanks for your review. pls take another look

@bowenli86
Copy link
Member Author

@flinkbot attention @sjwiesman @dawidwys @fhueske

@dawidwys
Copy link
Contributor

Sorry I missed the notifications. I have no major concerns regarding the content. However I would prefer somebody better with the linguistic aspect gave the final approval.

@bowenli86
Copy link
Member Author

@sjwiesman I removed the 1.10 info, please take another look

@sjwiesman
Copy link
Contributor

+1 to merge

@bowenli86 bowenli86 closed this in a20eb65 Nov 12, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants