Hi, Yang Guo!
Thnaks for driving this FIP. It must be a good improvement.
About Api design in client side. I want to raise the design of iceberg for
update properties[1] into discussion.
The difference is how the api is attached to. In iceberg, the api is attached
to `Table` instance instead of something like `Admin` or `Catalog`.
Here is an example of How iceberg does:
```
public interface Table {
/**
* Create a new {@link UpdateProperties} to update table properties and
commit the changes.
*
* @return a new {@link UpdateProperties}
*/
UpdateProperties updateProperties();
}
```
```
public interface UpdateProperties {
/**
* Add a key/value property to the table.
*
* @param key a String key
* @param value a String value
* @return this for method chaining
* @throws NullPointerException If either the key or value is null
*/
UpdateProperties set(String key, String value);
/**
* Remove the given property key from the table.
*
* @param key a String key
* @return this for method chaining
* @throws NullPointerException If the key is null
*/
UpdateProperties remove(String key);
}
```
I don't have a strong opinion on this, but following Iceberg's design approach
raises another question: how should we define the responsibilities of `Admin`
versus `Table`?
For example, methods like listOffsets and getLatestKvSnapshots are currently
placed in `Admin`, but they could also be appropriate for `Table`. This makes
the responsibility boundaries less clear.
cc @Jark What's your opinion on it.
[1]
https://github.com/apache/iceberg/blob/main/api/src/main/java/org/apache/iceberg/Table.java#L191
Best regards,
Yuxia
----- 原始邮件 -----
发件人: "Yang Guo" <[email protected]>
收件人: "dev" <[email protected]>
发送时间: 星期四, 2025年 9 月 11日 下午 9:33:38
主题: [DISCUSS] FIP-15: Alter Table Interface
Hi all,
Fluss server and client do not support alter tables now, but there are many
features required to alter table properties. After discussion with other
fluss developers, I'd like to draft this FIP about the alter table
interface.
This FIP-15 is to design an alter table interface. Briefly speaking it adds
an 'alterTable' API in both client and server side. Considering there will
be various different types of changes on a table (such as comments,
properties, buckets, columns, etc), we introduce a 'FlussTableChange' class
to distinguish them. It will also make servers easy to determine how to
operate on the table based on change types.
For mode details, you can see the FIP-15 draft:
https://cwiki.apache.org/confluence/display/FLUSS/FIP-15%3A+Alter+Table+Interface
I also have implemented a PR to alter table properties based on this
design, which could be a sample for this design:
https://github.com/apache/fluss/pull/1625
Thanks in advance and looking forward to any feedback from you.
Regards,
Yang Guo
