Hi, Yang Guo! Thanks for moving this forward. For the interfaces, I suggest using TableChange instead of FlussTableChange. Since we are always in Fluss, adding a "Fluss" prefix is a bit redundant. Another reason is that we might also use this interface when modifying lake tables, in which case we are not modifying Fluss tables.
Best regards, Liebing Yu On Fri, 12 Sept 2025 at 15:26, yuxia <[email protected]> wrote: > 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 >
