Skip to content

Tolerate lake table existent if the schema and properties matches when creating lake enabled table #846

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
1 of 2 tasks
wuchong opened this issue May 10, 2025 · 1 comment

Comments

@wuchong
Copy link
Member

wuchong commented May 10, 2025

Search before asking

  • I searched in the issues and found nothing similar.

Motivation

With #640, we synchronously create a datalake table in Paimon/Iceberg when creating a lake enabled table in Fluss. It is implemented by 3-steps:

  1. Sanity check for the table to create
  2. Create the datalake table in Paimon/Iceberg
  3. Create the table in Fluss

However, step#3 may fail if the table/db exists or for some reasons else and can result in in-consistent metadata between Paimon and Fluss. It's hard to support distributed transactions, but it's easy to support eventual consistency by idempotent writing. Therefore, we should tolerate if setp#2 the lake table exist but matches our schema and properties instead of throwing exceptions. Thus, we can have an eventual consistency for the metadata.

Solution

No response

Anything else?

No response

Willingness to contribute

  • I'm willing to submit a PR!
@wuchong
Copy link
Member Author

wuchong commented May 10, 2025

cc @luoyuxia , what do you think about this?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant