Hello! I went through the FIP another time as I did not remember doing it
already :)

I have additional questions beyond the first 2.

Let me paste those here and add:

1. Isn't the scope of the FIP misleading?
This FIP seems to be about removing system columns, but it primarily
proposes a new read mode named PARTITION_TIMESTAMP.
Is this because removing those columns prevents users from accessing data
on the lake?
If so:
 - how do user are supposed to do that now
 - What would change

2. How does this relate to union reads?
I am quite new to the community and Fluss. Could you explain how the new
PARTITION_TIMESTAMP mode relates to union reads?
If the answer is not obvious, perhaps this warrants a section in the FIP.

3. Why *"*Only auto partitioned table is supported in this mode"?
Why only for partitions generated by Fluss, and not for any partition that
represents a timestamp?

On Wed, Feb 4, 2026 at 4:50 PM Lorenzo Affetti <
[email protected]> wrote:

> Hello Yuxia!
> Thanks for the great FIP!
> I have some questions:
>
> 1. Isn't the scope of the FIP misleading?
> It seems this FIP is about removing system columns, but it primarily
> proposes a new read mode named PARTITION_TIMESTAMP.
>
> 2. How does this relate to union reads?
> I am quite new to the community and Fluss. Could you explain how the new
> PARTITION_TIMESTAMP mode relates to union reads?
> If the answer is not obvious, perhaps this warrants a section in the FIP.
>
> Thank you!
>
> On Tue, Jan 20, 2026 at 8:20 AM yuxia <[email protected]> wrote:
>
>> Hi, all.
>>
>> Currently, every Fluss lake table is automatically provisioned with three
>> mandatory system columns, __bucket , __offset , __timstamp (intended for
>> bucket and offset-based subscription as well as addition informartion
>> check).
>> While originally designed to allow clients to pinpoint specific data
>> offsets of specific buckets, the practical evolution of the ecosystem has
>> rendered this default behavior suboptimal for the dowstream since the
>> dowstream warehouse or BI tools do not expect these internal metadata
>> fields.
>>
>>
>> So, I'd like to propose FIP-27: Remove Mandatory System Columns From
>> Fluss Lake Tables [1] to remove the three mandatory system columns while
>> still keep compability.
>>
>> Welcome your feedback and suggestions on this proposal. Looking forward
>> to a productive discussion!
>>
>> [1]:
>> https://cwiki.apache.org/confluence/display/FLUSS/FIP-27%3A+Remove+Mandatory+System+Columns+From+Fluss+Lake+Tables
>>
>> Best regards,
>> Yuxia
>>
>
>
> --
> Lorenzo Affetti
> Senior Software Engineer @ Flink Team
> Ververica <http://www.ververica.com>
>


-- 
Lorenzo Affetti
Senior Software Engineer @ Flink Team
Ververica <http://www.ververica.com>

Reply via email to