Skip to content

Conversation

@snazy
Copy link
Member

@snazy snazy commented Dec 4, 2025

Add the NoSQL specific metastore persistence types including the mapping from and to *Polaris*Entity.

Add the NoSQL specific metastore persistence types including the mapping from and to `*Polaris*Entity`.
@github-project-automation github-project-automation bot moved this from PRs In Progress to Ready to merge in Basic Kanban Board Dec 8, 2025
@dimas-b dimas-b merged commit 90cff77 into apache:main Dec 8, 2025
15 checks passed
@github-project-automation github-project-automation bot moved this from Ready to merge to Done in Basic Kanban Board Dec 8, 2025
@snazy snazy deleted the nosql-types branch December 8, 2025 14:07
@singhpk234
Copy link
Contributor

Apologies @dimas-b but i am unable to understand the rush of getting these NoSQL huge PRs in and not giving community apporpriate time to review the code, I am strongly concerned about this, this pr is ~7k LOC the diff is so huge that it doesn't even render in github UI

This PR was raised ~4 days ago of which 2 days were weekend and i was reviewing these changes considering i have appropriate time, but i just open the github to see it was approved 7k LOC merged in less than a minute after approval, even when it had been called out the NoSQL impl is not following the practice we have already in the Polaris :

Screenshot 2025-12-08 at 9 06 23 AM

I request to please give more set eyes to get this massive code changes in.

cc @jbonofre @dennishuo @flyrain @collado-mike

@dimas-b
Copy link
Contributor

dimas-b commented Dec 8, 2025

@singhpk234 : I welcome you interest in the NoSQL Persistence code. The more developers get involved, the better code quality will be, I'm sure.

As to your specific points, the current guildelines indicate "two working days" as a reasonable time period for providing initial PR comments.

As for "rush", recent NoSQL PR basically chip off small code chunks from #1189, which has been available for interested parties to review for many months now (and some community members do have hands-on experience with it). It is in "draft" only to indicate that is it not meant to be merged whole, but it was mentioned in the original NoSQL proposal in March 2025 and multiple online meetings (IIRC). AFAIK, the community is in general agreement on accepting the NoSQL Persistence contribution.

These changes are isolated from the rest of the Polaris codebase and do not affect any existing code paths, as far as I can tell.

However, if you or someone have specific concerns about the new code after merging, by all means, let's discuss on the dev ML.

@dimas-b
Copy link
Contributor

dimas-b commented Dec 8, 2025

@singhpk234 : On the second reading, I'm not sure I actually understand whether your comment above applies to this PR or to #3135 ... If it's the latter, please note that your screenshot shows your comments as "pending" - noone but you was able to see them in GH before.

@singhpk234
Copy link
Contributor

@dimas-b, current guidelines just says about first round of comments and not when to merge, orthogonally, nevertheless we all agree that the current guidelines needs some refinement and hence we as a community we are working towards defining new one : #3067 and i strongly think LOC should be factor on this.

AFAIK, the community is in general agreement on accepting the NoSQL Persistence contribution

The community has recently expressed their concerns about what NoSQL meeting (12/2) i believe we all were there :
dev list : https://lists.apache.org/thread/t6ddtgk0wt92opphvy0o6lvx8pjk0go8
video ref : https://drive.google.com/file/d/1r_7bPtQEp7jdB1gtP15KvC_qLE6271Rf/view

  • the main questions why do we need to support all backend, why do we need to make yet another iceberg on top of database.
  • severe perf consideration and req to benchmark 1 catalog with 100k table with concurrent update randomly happening in any of the table

but instead of adressing them, that we are adding more and more code, i am unclear what happened to the things we discussed in the meeting are they just lost or they not considered concerns. At this point of time i don't think there is a concencus on NoSQL approach

second we had the mentor @fpapon of the project addiontally suggested we need minimum of 2 approvers in thread here : https://lists.apache.org/thread/hzxds729v5r68togbfx76l14f9m4bfj4

I am unsure starting a new ML to call this out is gonna make any difference if the above ones didn't.

I request again please give appropriate time for review, with the screenshot i wanted to share is i was indeed review (I know its only visible to me) but the review was not given appropriate time, before i could publish and if we would have just give
some time post your approval, I would have got notification that this PR is about to merge i need to publish my review even if its half baked, but in one minute it got merged.

@snazy
Copy link
Member Author

snazy commented Dec 8, 2025

@singhpk234 I appreciate you taking the time to review the code!
I totally understand that everybody has a ton of things on his plate and time is an extremely rare resource for everybody.

Regarding the two points you and @collado-mike mentioned, may I refer you both to @pingtimeout's email to the dev-ML from March 20th this year, where he mentioned this doc with a very detailed performance analysis? I admit, that it's been quite a while since that email was sent.
Let me note, that the benchmark was a very important foundational piece and that a bunch of optimizations addressing his findings were implemented in the (NoSQL) code base since then.
If you have different, reproducible results for such benchmarks, I would be glad to collaborate on the findings!

Let me also reply to your other point about "having to support all backends": I think this is driven by demand from the whole community, for example #844 from January this year, recently gotten even some more interest. In the recording you mentioned (I assume it is the one from Adam's presentation) I clearly stated that there is no intent to implement support for all thinkable database. What I clarified is that it is doable.

We have been discussing the whole NoSQL approach for quite a while, mentioning it repeatedly on the dev-ML, in community syncs and docs including this one from last year, which is open for comments since then.

There were also a public presentations held by @adam-christian-software quite some time ago, which he repeated recently.

The "big illustrative PR #1189", open for review for ~266 days, was explicitly intended to collect feedback. But it hasn't got many comments, despite asking continuously and repeatedly for it. Any feedback is more than welcome!

I apologize that I fail to see what else we could have done beside all the things that were already mentioned. Everybody's open for suggestions to streamline the process for such big changes!

@singhpk234
Copy link
Contributor

singhpk234 commented Dec 8, 2025

@snazy appreciate your response !

I have myself ran these benchmarks when i doing relational jdbc pg, but i am pretty confused on this being mentioned when the ask was very specific, please run a benchmark with 100k table and 1 catalog with a TPS 100, the benchmark mentioned by pierre is 50 TPS with 500 catalog, 65K namespace, 65K Tables, i don't think it remotely even address the case which is being requested and concerns folks have raise for this architecture Concurrent Benchmark configurations, so i would still consider this a very open question not being addressed.

"having to support all backends"

I haven't seen any DISCUSS thread and the agreement on the same ? I clearly see and you mention this too that a PPMC (@collado-mike ) is questioning the same. I am unclear at this point where was this decision made, My understanding is this effort started with an effort to add MongoDb support.

There were also a public presentations held by @adam-christian-software quite some time ago, which he repeated recently.

Precisely I happen to attend one of those really appreciate you all doing this and have started to contribute reviews ! I understand the design better.

Any feedback is more than welcome!

Precisely and I am happy too :) ! please just lets make sure we give other people enough time to give feedbacks.

snazy added a commit to snazy/polaris that referenced this pull request Feb 11, 2026
* Doc cleanup for local deployment (apache#3213)

* Doc cleanup for admin tool (apache#3214)

* Bump version from 1.0.0 to 1.2.0 and fix health port (apache#3211)

* fix(deps): update dependency io.opentelemetry:opentelemetry-bom to v1.57.0 (apache#3223)

* fix(deps): update dependency org.apache.commons:commons-text to v1.15.0 (apache#3233)

* fix(deps): update dependency software.amazon.awssdk:bom to v2.40.3 (apache#3234)

* Core: Add timeout and retry logic to Azure token fetch (apache#3113)

* update markdown lint check (apache#3187)

use tcort/github-action-markdown-link-check, gaurav-nelson/github-action-markdown-link-check is deprecated

* NoSQL: Add metastore types and mappings (apache#3207)

Add the NoSQL specific metastore persistence types including the mapping from and to `*Polaris*Entity`.

* NoSQL/nit: fix javadoc for `Realms` (apache#3229)

* Fix build issue for docker not found when using latest docker desktop (apache#3227)

* fix(deps): update dependency org.mongodb:mongodb-driver-sync to v5.6.2 (apache#3238)

* fix(deps): update immutables to v2.12.0 (apache#3240)

* fix(deps): update dependency io.micrometer:micrometer-bom to v1.16.1 (apache#3239)

* [Core, Bug] CreateEntitiesIfNotExist/CreatePrincipal not return the same entity persisted. (apache#3219)

The PR fixes the issue, "CreateEntitiesIfNotExist/CreatePrincipal not return the same entity persisted", by letting persistEntity return the entity persisted and include that in the EntityResult. The PR also include new unit tests to verify the behavior

* (feat) doc: Update Makefile to fix admonitions in helm doc and remove redundant sections (apache#3232)

* Change org.testcontainers:<dep> to org.testcontainers:testcontainers-<dep> (apache#3225)

* Helm: add support for topologySpreadConstraints (apache#3216)

* chore(deps): update registry.access.redhat.com/ubi9/openjdk-21-runtime docker tag to v1.23-6.1764764731 (apache#3241)

* NoSQL correctness tests: add missing `logback-test.xml` files (apache#3230)

* Add Docker-based Ceph + Polaris cluster setup (apache#3022)


---------

Co-authored-by: sarunas.svegzda <[email protected]>

* Service: Remove *CommitTableEvent, Add *UpdateTableEvent to Transactions (apache#3195)

* Update dependency pydantic to >=2.12.5,<2.13.0 (apache#2807)

* fix(deps): update dependency com.github.dasniko:testcontainers-keycloak to v4.0.1 (apache#3244)

* fix(deps): update mockito monorepo to v5.21.0 (apache#3245)

* Allow retrieving a config directly from a `Map` (apache#3220)

The current implementation deserializes the catalog configuration properties for each invocation of `getConfig*()` taking a `CatalogEntity`.

This change adds another `getConfig*()` variant that takes a `Map` to allow call sites to memoize the properties, where possible.

* Runtime/service: move getConfig() down to `IcebergCatalogHandler` (apache#3231)

All catalog specific functionality is implemented in `IcebergCatalogHandler`, whereas `IcebergCatalogAdapter` is meant to act as a "REST wrapper" to it.

This change moves the implementation of `getConfig` down to the handler, no functional changes.

* chore(deps): update quay.io/ceph/ceph docker tag to v20 (apache#3242)

* fix(deps): update quarkus platform and group to v3.30.3 (apache#3247)

* NoSQL: Prepare for NoSQL tests (apache#3235)

* Add an optional `bootstrapRealm()` implementation to `PolarisAuthzTestBase`
* Allow extending `IcebergCatalogHandlerAuthzTest`, move tests to `AbstractIcebergCatalogHandlerAuthzTest`
* No functional changes

* Shell script to verify staged release candidate artifacts (apache#2824)

Performs a bunch of verifications against a proposed (staged) release candidate using the new `tools/verify-release/verify-release.sh` script against Maven artifacts, main distributions and Helm chart.

Checks:
* GPG signature and checksum verifications
* All expected artifacts are present
* Build artifacts are reproducible (minus known exceptions)
  * jar files
  * Main distribution zip/tarball
  * Helm chart
* Build passes.
* DISCLAIMER/LICENSE/NOTICE files are present in artifacts that require those

More information in the added web site page.

Fixes apache#2822

---------

Co-authored-by: Pierre Laporte <[email protected]>

* Core: Add GCP service account impersonation for credentials. (apache#3246)

* fix(deps): update dependency ch.qos.logback:logback-classic to v1.5.22 (apache#3253)

* fix(deps): update dependency com.google.cloud:google-cloud-iamcredentials to v2.80.0 (apache#3254)

* feat: pass principal name as part of aws subscoped credentials session (apache#3224)

* feat: pass principal name as part of aws subscoped credentials session name

* feat: resolve principal from CurrentIdentityAssociation

* fix: handle principal injection for async tasks

* add feature flag for principal name include

* add changelog, address comments

* handle null identity, refactor tests

* Added user token to the PolarisPrincipal (apache#3236)

* Added user token to the PolarisPrincipal

* added redacted

* Fix compilation failures in GcpCredentialsStorageIntegrationTest (apache#3257)

* chore(deps): update github artifact actions (apache#3260)

* chore(deps): update medyagh/setup-minikube action to v0.0.21 (apache#3264)

* NoSQL: Metastore implementation (apache#3237)

* Fix typo in nosql (apache#3263)

* Corrected a typo in a key configuration parameter in the 1.2.0 release notes (apache#3262)

* fix(deps): update dependency software.amazon.awssdk:bom to v2.40.8 (apache#3271)

* Add NOTES.txt to Helm chart with installation instructions (apache#3173)

* Add NOTES.txt to Helm chart with installation instructions

Provides port-forward commands, health check endpoint, and log viewing for users after installation.

* Fix helm unittest for GH action (apache#3279)

* [doc]: Doc fix for CLI usage (apache#3215)

* [doc]: Add doc for helm prod deployment (apache#3265)

* chore(deps): update docker.io/prom/prometheus docker tag to v3.8.1 (apache#3282)

* chore(deps): update dependency jupyterlab to v4.5.1 (apache#3275)

* fix(deps): update dependency com.google.cloud:google-cloud-storage-bom to v2.61.0 (apache#3274)

* chore(deps): update dependency mypy to >=1.19, <=1.19.1 (apache#3272)

* Bump to 1.4.0-incubating-SNAPSHOT (apache#3181)

* Bump to 1.4.0-incubating-SNAPSHOT

* Update Python client version

* Add exclude check note in the release guide (apache#3182)

* Add exclude check note in the release guide

* Update site/content/release-guide.md

Co-authored-by: Robert Stupp <[email protected]>

---------

Co-authored-by: Robert Stupp <[email protected]>

* docs(tools): Create the Tools Section in the Docs (apache#3189)

* fix(deps): update dependency org.apache.logging.log4j:log4j-core to v2.25.3 (apache#3283)

* Add Polaris Community Meeting 20251211 (apache#3284)

* chore(deps): update dependency pre-commit to v4.5.1 (apache#3286)

* fix(deps): update dependency com.google.cloud:google-cloud-iamcredentials to v2.81.0 (apache#3287)

* ensure AddressResolver supports localhost even if ipv6 is disabled in sysctl but not /etc/hosts (apache#3285)

* Migrate to Jackson mapper builder pattern (apache#3269)

Mappers and factories are fully immutable objects in Jackson 3. This change is rather a no-op, but migrates the code to use the builder-pattern.

This is only a little building-block for "real" Jackson 3 support, there's more to do and more that's required from other frameworks.

* fix(deps): update quarkus platform and group to v3.30.4 (apache#3291)

* Rework release guide to include workflows (apache#3273)

* Add a release guides section
* Rename current release guide to manual (deprecated)
* Add new semi-automated release guide
* Move release verification guide under release guides section
* Add scss style for better screenshot separation
* Add redirection from old pages to new ones

Co-authored-by: Robert Stupp <[email protected]>

* Site: Fix typos in release guide (apache#3296)

* [chore]: Match openapi-generator-cli version in build system to dependency (apache#3266)

* Fix openapi-generator-cli version in build system

* Fix openapi-generator-cli version in build system

* chore(deps): update registry.access.redhat.com/ubi9/openjdk-21-runtime docker tag to v1.24-1 (apache#3297)

* chore(deps): update dependency openapi-generator-cli to v7.17.0 (apache#3298)

* chore(deps): update docker.io/mongo docker tag to v8.2.3 (apache#3299)

* chore(deps): update mongo docker tag to v8.2.3 (apache#3300)

* fix(deps): update dependency io.smallrye.config:smallrye-config-core to v3.15.0 (apache#3302)

* fix(deps): update dependency org.apache.httpcomponents.client5:httpclient5 to v5.6 (apache#3301)

* chore(deps): update plugin com.gradle.develocity to v4.3 (apache#3248)

* Unify mongo image ref (apache#3303)

To prevent duplicate version-bump PRs like apache#3299 and apache#3300

* fix(deps): update dependency org.testcontainers:testcontainers-bom to v2.0.3 (apache#3277)

* Disable sectionPagesMenu (apache#3312)

* Remove docker-java.properties (apache#3307)

* Ensure release can only run from specific SHA (apache#3295)

* Ensure release publish workflow can only run from last RC (apache#3290)
* Enable use of second release workflow for RC>0
* Patch 3rd workflow to support commits with multiple RC tags
* Force 4th workflow to only run from a release branch
* Update release guide to match new workflows

* fix(deps): update dependency ch.qos.logback:logback-classic to v1.5.23 (apache#3308)

* fix(deps): update dependency software.amazon.awssdk:bom to v2.40.13 (apache#3309)

* chore(deps): update registry.access.redhat.com/ubi9/openjdk-21-runtime docker tag to v1.24-2 (apache#3313)

* NoSQL: reduce heap pressure when running tests

Some tests generate a lot of realms, likely one realm per test case. While the amount of data per realm is not much, it is nontheless nice to remove that data immediately (for tests).

The maintenance service, which purges data of eligible realms, cannot be run against the in-memory backend (different JVM).

This change adds a rather "test only" workaround to purge the realm data in the in-memory backend immediately.

* NoSQL: Metastore maintenance

Implementation of the NoSQL meta-store maintenance implementation. It adds the meta-store specific handling to the existing NoSQL maintenance service to purge unreferenced and unneeded data from the database.

* NoSQL: Add to runtime-service

* NoSQL: Add metastore-maintenance to admin tool

* NoSQL: revert LICENSE file change

* Last merged commit 62d774f

---------

Co-authored-by: Yong Zheng <[email protected]>
Co-authored-by: Mend Renovate <[email protected]>
Co-authored-by: fivetran-rahulprakash <[email protected]>
Co-authored-by: Kevin Liu <[email protected]>
Co-authored-by: Honah (Jonas) J. <[email protected]>
Co-authored-by: Šarūnas Švėgžda <[email protected]>
Co-authored-by: sarunas.svegzda <[email protected]>
Co-authored-by: Adnan Hemani <[email protected]>
Co-authored-by: Pierre Laporte <[email protected]>
Co-authored-by: Talat UYARER <[email protected]>
Co-authored-by: Tornike Gurgenidze <[email protected]>
Co-authored-by: cccs-cat001 <[email protected]>
Co-authored-by: Alexandre Dutra <[email protected]>
Co-authored-by: zgxme <[email protected]>
Co-authored-by: Tamas Mate <[email protected]>
Co-authored-by: JB Onofré <[email protected]>
Co-authored-by: Adam Christian <[email protected]>
Co-authored-by: Romain Manni-Bucau <[email protected]>
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

Successfully merging this pull request may close these issues.

3 participants