Hi everyone,
thanks for your opinions. I will go with option A then and perform the
necessary refactorings.
In the meantime, please feel free to try out PTFs and give feedback. I'm
sure there will be more iterations in the upcoming weeks/months.
Thanks,
Timo
On 23.06.25 10:12, Martijn Visser wrote:
Hi all,
I think option A is the best suggestion out of these. It's semantically
accurate and aligns with established database and SQL terminology.
Best regards,
Martijn
On Fri, Jun 20, 2025 at 2:15 PM Arvid Heise <ar...@apache.org> wrote:
I'm also in favor of Option A of the presented options.
I had one additional idea (Option F) that mixes two approaches B+E
ROW_WISE_TABLE
SET_PARTITIONED_TABLE
You'd have ROW and SET that comes from the SQL standard but you also have a
stronger connection between SET and partitioning.
Best,
Arvid
On Fri, Jun 20, 2025 at 3:01 AM Hao Li <h...@confluent.io.invalid> wrote:
+1 for option A. It's consistent with calcite naming.
On Thu, Jun 19, 2025 at 11:38 AM Sergey Nuyanzin <snuyan...@gmail.com>
wrote:
Thanks for raising this
+1 for option A
On Thu, Jun 19, 2025 at 4:05 PM Gustavo de Morais
<gustavopg...@gmail.com> wrote:
Hi Timo,
+1 (non-binding) for option A. Thanks for trying to address feedback
quickly.
Kind regards,
Gustavo de Morais
On Thu, 19 Jun 2025 at 15:51, Timo Walther <twal...@apache.org>
wrote:
Hi everyone,
I'm currently polishing FLIP-440, I would like to apply some last
minute
changes before the first release of PTFs for Flink 2.1. I've
already
collected initial user feedback and it seems that the name for
annotations of table arguments is not precise enough.
As always, naming is a hard problem in software engineering.
For background, please take a look at this docs section:
https://nightlies.apache.org/flink/flink-docs-master/docs/dev/table/functions/ptfs/#table-semantics-and-virtual-processors
Currently, a PTF signature can look like when taking a table as an
argument:
// Untyped with set semantics
eval(@ArgumentHint(TABLE_AS_SET) Row order);
// Typed with set semantics
eval(@ArgumentHint(TABLE_AS_SET) Order order);
// Untyped with row semantics
eval(@ArgumentHint(TABLE_AS_ROW) Row order);
// Typed with row semantics
eval(@ArgumentHint(TABLE_AS_ROW) Order order);
The annotation value confuses people, so I would ask for renaming
this
part of the API.
Option A:
ROW_SEMANTIC_TABLE
SET_SEMANTIC_TABLE
Option B:
ROW_WISE_TABLE
SET_WISE_TABLE
Option C:
ROW_SCOPED_TABLE
SET_SCOPED_TABLE
Option D:
KEYED_TABLE
UNKEYED_TABLE
Option E:
PARTITIONED_TABLE
ROW_WISE_TABLE
Option A/B/C are closer to SQL standard and not too far away from
current docs. Option D is closer to Flink DataStream API but could
be
confusing if no PARTITION BY clause is given but still the table
could
be keyed. Option E neither takes SQL standard nor DataStream API
as a
reference.
Personally, I would vote for Option A.
Looking forward to your opinion.
Cheers,
Timo
--
Best regards,
Sergey
