Mutable objects used for immutable values #772 #1596

fabio-rizzo-01 · 2025-05-15T14:50:18Z

Updated Polaris entity objects to use builders instead of normal constructors and removed all the set methods to guarantee object immutability.
All the other changes are refactoring based on those changes.

snazy · 2025-05-15T15:27:42Z

I like the removal of all the setters!
However, since these types now look pretty much how those would look like when using immutables, mind going down that route? That would also remove all the hand-written Builders.

pingtimeout · 2025-05-15T15:43:44Z

I agree with Robert. I think this PR does not fully embrace the immutable pattern.

The class fields are not final, which would clearly establish the intent of those objects being immutable.
Adding the Builder subclasses adds a lot of code that could be automatically generated
(nit) It could even be possible to annotate the classes with @Immutable (from jcip) to enable an extra verification step in the IDE

It would be good to explore the immutables library to address some of these points.

Note that this PR contains a removal of some utility copy-constructors (PolarisEntityCore from PolarisBaseEntity), which might not be related?

singhpk234 · 2025-05-15T16:17:02Z

+1 to PolarisImmutables

fabio-rizzo-01 · 2025-05-15T16:43:00Z

I like the removal of all the setters! However, since these types now look pretty much how those would look like when using immutables, mind going down that route? That would also remove all the hand-written Builders.

From the bug description I thought the point was to make those object not mutable, i didn't think there was a library already there hence why I created the builders. can you guys point me in the right direction thx ? @singhpk234

eric-maynard · 2025-05-15T17:01:00Z

@fabio-rizzo-01 I think the ask is that you use this interface.

Besides this, I think we should try to minimize the changes that callers need to make as much as possible.

fabio-rizzo-01 · 2025-05-16T08:51:58Z

@fabio-rizzo-01 I think the ask is that you use this interface.

Besides this, I think we should try to minimize the changes that callers need to make as much as possible.

Looking at that interface and seeing where it is used, it seems to me that using it would require even more changes that what I already did.

Taking PolarisEntityCore as an example, to convert that to an immutable object I'd have to create an interface (something like PolarisEntityCoreInt) that uses PolarisImmutable annotation, that would generate a class called Immutable PolarisEntityCoreInt. So all the code that is using PolarisEntityCore object it needs to be updated to use the new immutable object.

Is this what you guys are suggesting ? @snazy @singhpk234

eric-maynard · 2025-05-16T17:36:04Z

Personally I'm fine with you not using @PolarisImmutable -- I still haven't figured out why we need that or why my IDE so often doesn't seem to like it:

But I do think this PR makes quite a few changes, such as those to TransactionalMetaStoreManagerImpl.java, which could be reduced or elimated. For example, does the method setGrantRecordsVersion really need to go away? If it does, can we implement a cloning method like withGrantRecordsVersion?

fabio-rizzo-01 · 2025-05-19T08:30:31Z

Personally I'm fine with you not using @PolarisImmutable -- I still haven't figured out why we need that or why my IDE so often doesn't seem to like it:

But I do think this PR makes quite a few changes, such as those to TransactionalMetaStoreManagerImpl.java, which could be reduced or elimated. For example, does the method setGrantRecordsVersion really need to go away? If it does, can we implement a cloning method like withGrantRecordsVersion?

The builder in the PolarisBaseEntity has a constructor that allows you to pass an entity into it, that is what I'm using inTransactionalMetaStoreManagerImpl.java to update properties and the grant record version.

Like here https://github.com/apache/polaris/pull/1596/files#diff-5327c1f118c61e497b4fb5b3200002388a3a4bcde3b44d91403d202bac6a0cccR293

snazy · 2025-05-19T09:36:42Z

Taking PolarisEntityCore as an example, to convert that to an immutable object I'd have to create an interface (something like PolarisEntityCoreInt) that uses PolarisImmutable annotation, that would generate a class called Immutable PolarisEntityCoreInt. So all the code that is using PolarisEntityCore object it needs to be updated to use the new immutable object.

Is this what you guys are suggesting ? @snazy @singhpk234

Yes.

fabio-rizzo-01 · 2025-05-19T13:20:27Z

Taking PolarisEntityCore as an example, to convert that to an immutable object I'd have to create an interface (something like PolarisEntityCoreInt) that uses PolarisImmutable annotation, that would generate a class called Immutable PolarisEntityCoreInt. So all the code that is using PolarisEntityCore object it needs to be updated to use the new immutable object.
Is this what you guys are suggesting ? @snazy @singhpk234

Yes.

Ok. In doing so every entity object in Polaris will need to change because every entity (catalog, namespace, etc.) extends PolarisEntity that extends PolarisBaseEntity. Correct?
I just want to be sure before I start rewriting the code that I'm not going down the wrong path.

fabio-rizzo-01 · 2025-06-10T08:59:52Z

Thanks @fabio-rizzo-01 for doing this! +1 on using annotation PolarisImmutable.

I understand the push to use PolarisImmutable, but I've identified some issues with its implementation:

Our object hierarchy consists of Core -> Base -> Entity -> Catalog, with each class extending the previous one. Applying PolarisImmutable to Core and Base would result in two new immutable classes, both of which are final. This prevents further extension of the immutable Base class, disrupting our current hierarchy.

While there are workarounds, they would necessitate significant code changes, which I believe should be minimized in this part of the repository.

@snazy @singhpk234 @flyrain

…feature/immutability-772 # Conflicts: # client/python/pyproject.toml # plugins/spark/v3.5/spark/LICENSE # plugins/spark/v3.5/spark/NOTICE

author Mend Renovate <[email protected]> 1749165686 +0200 committer Rizzo Cascio, Fabio <[email protected]> 1749646499 +0100 # This is a combination of 2 commits. # This is the 1st commit message: Mutable objects used for immutable values apache#772: resolved conflicts

…feature/immutability-772

flyrain · 2025-06-12T22:26:29Z

Agreed. The immutable makes more sense to the leaf classes, like CatalogEntity, as the generated immutable classes are final, we cannot leverage the autogenerated builder in its subclasses. I'm OK to relies on manual builder for non-leaf classes. WDYT? @snazy @singhpk234

author Mend Renovate <[email protected]> 1749165686 +0200 committer Rizzo Cascio, Fabio <[email protected]> 1749646499 +0100 # This is a combination of 2 commits. # This is the 1st commit message: Mutable objects used for immutable values apache#772: resolved conflicts

…on tests

…feature/immutability-772 # Conflicts: # client/python/pyproject.toml # plugins/spark/v3.5/spark/LICENSE # plugins/spark/v3.5/spark/NOTICE # polaris-core/src/main/java/org/apache/polaris/core/persistence/AtomicOperationMetaStoreManager.java

# This is the 1st commit message: apache#772 fixed integration tests and synched with main Mypy did a new release 1.16.1 and it cause our CI to fail for about 20 minutes due to missing wheel (upload not completed) ``` | Unable to find installation candidates for mypy (1.16.1) | | This is likely not a Poetry issue. | | - 14 candidate(s) were identified for the package | - 14 wheel(s) were skipped as your project's environment does not support the identified abi tags | | Solutions: | Make sure the lockfile is up-to-date. You can try one of the following; | | 1. Regenerate lockfile: poetry lock --no-cache --regenerate | 2. Update package : poetry update --no-cache mypy | | If neither works, please first check to verify that the mypy has published wheels available from your configured source that are compatible with your environment- ie. operating system, architecture (x86_64, arm64 etc.), python interpreter. | ``` This PR temporarily restrict the mypy version to avoid the similar issue. We may consider bring poetry.lock back to git tracking so we won't automatically update test dependencies all the time # This is the commit message apache#48: Remove `.github/CODEOWNERS` (apache#1902) As per this [dev-ML discussion](https://lists.apache.org/thread/jjr5w3hslk755yvxy8b3z45c7094cxdn) # This is the commit message apache#49: Rename quarkus as runtime (apache#1695) # This is the commit message apache#50: parent 3185adf author Mend Renovate <[email protected]> 1749165686 +0200 committer Rizzo Cascio, Fabio <[email protected]> 1749646499 +0100 # This is a combination of 2 commits. # This is the 1st commit message: Mutable objects used for immutable values apache#772: resolved conflicts # This is the commit message apache#51: Mutable objects used for immutable values apache#772: fixed integration tests # This is the commit message apache#52: parent 3185adf author Mend Renovate <[email protected]> 1749165686 +0200 committer Rizzo Cascio, Fabio <[email protected]> 1749646499 +0100 # This is a combination of 2 commits. # This is the 1st commit message: Mutable objects used for immutable values apache#772: resolved conflicts Mutable objects used for immutable values apache#772: added final to base and core fields Mutable objects used for immutable values apache#772: fixed tests

…feature/immutability-772 # Conflicts: # client/python/pyproject.toml # plugins/spark/v3.5/spark/LICENSE # plugins/spark/v3.5/spark/NOTICE # polaris-core/src/main/java/org/apache/polaris/core/persistence/AtomicOperationMetaStoreManager.java

plugins/spark/v3.5/spark/NOTICE

flyrain

Thanks a lot @fabio-rizzo-01 for working on it! LGTM. Left two minor comments, which are not blockers. We can merge it once reverting the changes in the NOTICE.

flyrain · 2025-06-26T20:29:15Z

polaris-core/src/main/java/org/apache/polaris/core/entity/PolarisBaseEntity.java

+   * @param grantRecordsVersion The new grant records version to be set.
+   * @return A new PolarisBaseEntity instance with the updated grant records version.
+   */
+  public PolarisBaseEntity withGrantRecordsVersion(int grantRecordsVersion) {


Name suggestion: would it be more descriptive with a name like cloneWithGrantRecordsVersion()

flyrain · 2025-06-26T20:37:38Z

polaris-core/src/main/java/org/apache/polaris/core/persistence/BaseMetaStoreManager.java

+    PolarisBaseEntity.Builder entityBuilder = new PolarisBaseEntity.Builder(entity);
+    entityBuilder.lastUpdateTimestamp(entity.getCreateTimestamp());
+    entityBuilder.dropTimestamp(0);
+    entityBuilder.purgeTimestamp(0);
+    entityBuilder.toPurgeTimestamp(0);
+    return entityBuilder.build();


Minor suggestion:

Suggested change

PolarisBaseEntity.Builder entityBuilder = new PolarisBaseEntity.Builder(entity);

entityBuilder.lastUpdateTimestamp(entity.getCreateTimestamp());

entityBuilder.dropTimestamp(0);

entityBuilder.purgeTimestamp(0);

entityBuilder.toPurgeTimestamp(0);

return entityBuilder.build();

return new PolarisBaseEntity.Builder(entity)

.lastUpdateTimestamp(entity.getCreateTimestamp())

.dropTimestamp(0)

.purgeTimestamp(0)

.toPurgeTimestamp(0)

.build();

fabio-rizzo-01 · 2025-06-27T08:42:37Z

Thanks a lot @fabio-rizzo-01 for working on it! LGTM. Left two minor comments, which are not blockers. We can merge it once reverting the changes in the NOTICE.

the notice has been reverted yesterday, it shouldn't be in the PR anymore

flyrain · 2025-06-27T15:56:41Z

Thanks @fabio-rizzo-01 for working on it. Thanks everyone for the review.

brooklynrob · 2025-06-27T20:54:42Z

Congratulations @fabio-rizzo-01. Tremendous contribution. And thank you to everyone who took the time to review this.

* Exclude unused dependency for polaris spark client dependency (apache#1933) * enable ETag integration tests (apache#1935) tests were added in 8b5dfa9 and afaict supposed to get enabled after ec97c1b * Fix Pagination for Catalog Federation (apache#1849) Details can be found in this issue: apache#1848 * Update doc to fix docker build inconsistency issue (apache#1946) * Simplify install dependency doc (apache#1941) * Simply getting start doc * Simply install dependecy doc * Minor words change * Fix admin tool for quick start (apache#1945) When attempting to use the `polaris-admin-tool.jar` to bootstrap a realm, the application fails with a `jakarta.enterprise.inject.UnsatisfiedResolutionException` because it cannot find a `javax.sql.DataSource` bean. Detail in apache#1943 This issue occurs because `quarkus.datasource.db-kind`is a build-time property in Quarkus. Its value must be defined during the application's build process to enable the datasource extension and generate the necessary CDI bean producer (ref: https://quarkus.io/guides/all-config#quarkus-datasource_quarkus-datasource-db-kind). I think we only support postgres for now, thus, I set `quarkus.datasource.db-kind=postgresql`. This can be problematic if we later want to support more data sources other than postgres. There are couple options we have for this such as use multiple named datasources in the config during build time. But this may be out of scope of this PR. I am open for more discussion on this, but for the time being, it may be better to unblock people who are trying to use the quick start doc. Sample output for the bootstrap container after the fix: ``` ➜ polaris git:(1943) docker logs polaris-polaris-bootstrap-1 Realm 'POLARIS' successfully bootstrapped. Bootstrap completed successfully. ``` * fix(build): Fix deprecation warnings in FeatureConfiguration (apache#1894) * Fix NPE in listCatalogs (apache#1949) listCatalogs is non-atomic. It first atomically lists all entities and then iterates through each one and does an individual loadEntity call. This causes an NPE when calling `CatalogEntity::new`. I don't think it's ever useful for listCatalogsUnsafe to return null since the caller isn't expecting a certain length of elements, so I just filtered it there. * Fix doc for sample log and default password (apache#1951) Minor updates for the quick start doc: 1. update sample output to reflect with the latest code 2. update default password to the right value 3. remove trailing space * Optimize the location overlap check with an index (apache#1686) The location overlap check for "sibling" tables (those which share a parent) has been a performance bottleneck since its introduction, but we haven't historically had a good way around this other than just disabling the check. <hr> ### Current Behavior The current logic is that when we create a table, we list all sibling tables and check each and every one to ensure there is no location overlap. This results in O(N^2) checks when adding N tables to a namespace, quickly becoming untenable. With the `CreateTreeDataset` [benchmark](https://github.com/eric-maynard/polaris-tools/blob/main/benchmarks/src/gatling/scala/org/apache/polaris/benchmarks/simulations/CreateTreeDataset.scala) I tested creating 5000 sibling tables using the current code: It is apparent that latency increases over time. Runs took between 90 and 200+ seconds, and Polaris instances with a small memory allocation were prone to crashing due to OOMs: ### Proposed change This PR adds a new persistence API, `hasOverlappingSiblings`, which if implemented can be used to directly check for the presence of siblings at the metastore layer. This API is implemented for the JDBC metastore in a new schema version, and some changes are made to account for an evolving schema version now and in the future. This implementation breaks a location down into components and queries for a sibling at each of those locations, so a new table at location `s3://bucket/root/n1/nA/t1/` will require checking for an entity with location `s3://bucket/`, `s3://bucket/root/`, `s3://bucket/root/n1/`, `s3://bucket/root/n1/nA/`, and finally `s3://bucket/root/n1/nA/t1/%`. All of this can be done in a single query which makes a single pass over the data. The query is optimized by the introduction of a new index over a new _location_ column. With the changes enabled, I tested creating 5000 sibling tables: Latency is stable over time, and runs consistently completed in less than 30 seconds. I did not observe any OOMs when testing with the feature enabled. * Add SUPPORTED_EXTERNAL_CATALOG_AUTHENTICATION_TYPES feature configuration (apache#1931) * Add SUPPORTED_FEDERATION_AUTHENTICATION_TYPES feature configuration * Add unit tests * Update Helm chart version (apache#1957) * Remove the maintainer list in Helm Chart README (apache#1962) * Use multi-lines instead of single line (apache#1961) * Fix invalid sample script in CLI doc (apache#1964) * Fix hugo blockquote (apache#1967) * Fix hugo blockquote * Add license header * Fix lint rules (apache#1953) * Mutable objects used for immutable values (apache#1596) * fix: Only include project LICENSE and NOTICE in Spark Client Jar (apache#1950) * Add Sushant as a collaborator (apache#1956) * Adds missing Google Flatbuffers license information (apache#1968) * fix: Typo in Spark Client Build File (apache#1969) debugrmation * Python code format (apache#1954) * test(integration): refactor PolarisRestCatalogIntegrationTest to run against any cloud provider (apache#1934) * Make Catalog Integration Test suite cloud native * Fix admin tool doc (apache#1977) * Fix admin tool doc * Fix admin tool doc * Update release-guide.md (apache#1927) * Add relational-jdbc to helm (apache#1937) Motivation for the Change Polaris needs to support relational-jdbc as the default persistence type for simpler database configuration and better cloud-native deployment experience. Description of the Status Quo (Current Behavior) Currently, the Helm chart only supports eclipse-link persistence type as the default, which requires complex JPA configuration with persistence.xml files. Desired Behavior Add relational-jdbc persistence type support to Helm chart Use relational-jdbc as the default persistence type Inject JDBC configuration (username, password, jdbc_url) through Kubernetes Secrets as environment variables Maintain backward compatibility with eclipse-link Additional Details Updated persistence-values.yaml for CI testing Updated test coverage for relational-jdbc configuration JDBC credentials are injected via QUARKUS_DATASOURCE_* environment variables from Secret Secret keys: username, password, jdbc_url * Add CHANGELOG (apache#1952) * Add rudimentary CHANGELOG.md * Add the Jetbrains Changelog Gradle plugin to help managing CHANGELOG.md * Share Polaris Community Meeting for 2025-06-26 (apache#1978) * Correct javadoc text in generateOverlapQuery() (apache#1975) * Fix javadoc warning: invalid input: '&' * Correct javadoc text in generateOverlapQuery() * Do not serialize null properties in the management model (apache#1955) * Ignore null values in JSON output * This may have an impact on existing client, but it is not likely to be substantial because normally absent properties should be treated the same as having `null` values. * This change enables adding new optional fields to the Management API while maintaining backward compatibility in the future: New properties will not be exposed to clients unless a value for them in explicitly set. * Add OpenHFT in Spark plugin LICENSE (apache#1979) * Add additional unit and integration tests for etag functionality (apache#1972) * Additional unit test for Etags * Added a few corner case IT tests for testing etags with schema changes. * Added IT tests to test changes after DDL and DML * Add options to the bootstrap command to specify a schema file (apache#1942) Instead of always using the hardcoded `schema-v1.sql` file, it would be nice if users could specify a file to bootstrap from. This is especially relevant after apache#1686 which proposes to add a new "version" of the schema. * Added support for `s3a` scheme (apache#1932) * Fix the sign failure (apache#1926) * Fix doc to remove outdated note about fine-grained access controls support (apache#1983) Minor update for the access control doc: 1. Remove the misleading section on privileges can only be granted at catalog level. I've tested the fine-grained access controls and confirmed that privileges can be applied to an individual table in the catalog. * Add support for catalog federation in the CLI (apache#1912) The CLI currently only supports the version of EXTERNAL catalogs that was present in 0.9.0. Now, EXTERNAL catalogs can be configured with various configurations relating to federation. This PR updates the CLI to better match the REST API so that federated catalogs can be easily set up in the CLI. * fix: Remove db-kind in helm chart (apache#1987) * Add a Spark session builder for the tests (apache#1985) * Fix doc for CLI update (apache#1994) PR for apache#1866 * Improve createPrincipal example in API docs (apache#1992) In apache#1929 it was pointed out that the example in the Polaris docs suggests that users can provide a client ID during principal creation: . . . This PR attempts to fix this by adding an explicit example to the spec. * Add doc for repair option (apache#1993) PR for apache#1864 * Refactor relationalJdbc in helm (apache#1996) * Add regression test coverage for Spark Client with package conf (apache#1997) * Remove unnecessary `InputStream.close` call (apache#1982) apache#1942 changed the way that the bootstrap init script is handled, but it added an extra `InputStream.close` call that shouldn't be needed after the BufferedReader [here](https://github.com/apache/polaris/pull/1942/files#diff-de43b240b5b5e07aba7e89f5515a417cefd908845b85432f3fcc0819911f3e2eR89) is closed. This PR removes that extra call. * Materialize Realm ID for Session Supplier in JDBC (apache#1988) It was discovered that the Session Supplier maps used in the MetaStoreManagerFactory implementations were passing in RealmContext objects to the supplier directly and then using the RealmContext objects to create BasePersistence implementation objects within the supplier. This supplier is cached on a per-realm basis in most MetaStoreManagerFactory implementations. RealmContext objects are request-scoped beans. As a result, if any work is being done outside the scope of the request, such as during a Task, any calls to getOrCreateSessionSupplier for creating a BasePersistence implementation will fail as the RealmContext object is no longer available. This PR will ensure for the JdbcMetaStoreManagerFactory that the Realm ID is materialized from the RealmContext and used inside the supplier so that the potentially deactivated RealmContext object does not need to be used in creating the BasePersistence object. Given that we are caching on a per-realm basis, this should not introduce any unforeseen behavior for the JdbcMetaStoreManagerFactory as the Realm ID must match exactly for the same supplier to be returned from the Session Supplier map. * rebase/changes * minor refactoring * Last merged commit 8fa6bf2 --------- Co-authored-by: Yun Zou <[email protected]> Co-authored-by: Christopher Lambert <[email protected]> Co-authored-by: Rulin Xing <[email protected]> Co-authored-by: MonkeyCanCode <[email protected]> Co-authored-by: Alexandre Dutra <[email protected]> Co-authored-by: Andrew Guterman <[email protected]> Co-authored-by: Eric Maynard <[email protected]> Co-authored-by: Pooja Nilangekar <[email protected]> Co-authored-by: Yufei Gu <[email protected]> Co-authored-by: fabio-rizzo-01 <[email protected]> Co-authored-by: Russell Spitzer <[email protected]> Co-authored-by: Sushant Raikar <[email protected]> Co-authored-by: Jiwon Park <[email protected]> Co-authored-by: Dmitri Bourlatchkov <[email protected]> Co-authored-by: JB Onofré <[email protected]> Co-authored-by: Sandhya Sundaresan <[email protected]> Co-authored-by: Pavan Lanka <[email protected]> Co-authored-by: CG <[email protected]> Co-authored-by: Adnan Hemani <[email protected]>

fabio-rizzo-01 requested review from adutra, ashvina, collado-mike, dennishuo, dimas-b, eric-maynard, jackye1995, jbonofre and vvcephei as code owners May 15, 2025 14:50

github-project-automation bot added this to Basic Kanban Board May 15, 2025

fabio-rizzo-01 requested review from HonahX, MonkeyCanCode, RussellSpitzer, ebyhr, flyrain, pingtimeout, singhpk234, snazy and takidau as code owners May 15, 2025 14:50

github-project-automation bot moved this to PRs In Progress in Basic Kanban Board May 15, 2025

fabio-rizzo-01 and others added 2 commits June 11, 2025 13:44

Mutable objects used for immutable values apache#772: fixed tests

7a6962f

Mutable objects used for immutable values apache#772: fixed tests

f4e55a3

fabio-rizzo-01 force-pushed the feature/immutability-772 branch from f9c6128 to f4e55a3 Compare June 11, 2025 12:48

fabio-rizzo-01 and others added 5 commits June 11, 2025 13:53

Mutable objects used for immutable values apache#772: synch from main

4bcb3d8

Merge remote-tracking branch 'private/feature/immutability-772' into …

de311e6

…feature/immutability-772 # Conflicts: # client/python/pyproject.toml # plugins/spark/v3.5/spark/LICENSE # plugins/spark/v3.5/spark/NOTICE

parent 3185adf

cbc5ce0

author Mend Renovate <[email protected]> 1749165686 +0200 committer Rizzo Cascio, Fabio <[email protected]> 1749646499 +0100 # This is a combination of 2 commits. # This is the 1st commit message: Mutable objects used for immutable values apache#772: resolved conflicts

Merge remote-tracking branch 'private/feature/immutability-772' into …

0f2df19

…feature/immutability-772

Merge branch 'main-latest' into feature/immutability-772

de4ba5b

renovate-bot and others added 5 commits June 18, 2025 17:11

parent 3185adf

50caac6

author Mend Renovate <[email protected]> 1749165686 +0200 committer Rizzo Cascio, Fabio <[email protected]> 1749646499 +0100 # This is a combination of 2 commits. # This is the 1st commit message: Mutable objects used for immutable values apache#772: resolved conflicts

Mutable objects used for immutable values apache#772: fixed integrati…

92aa3c7

…on tests

fabio-rizzo-01 force-pushed the feature/immutability-772 branch from 4cc0be6 to f5eec79 Compare June 20, 2025 15:05

fabio-rizzo-01 added 2 commits June 20, 2025 16:13

Mutable objects used for immutable values apache#772: synch from main

467f9fa

Mutable objects used for immutable values apache#772: synch from main

5b4a09e

sfc-gh-ygu reviewed Jun 25, 2025

View reviewed changes

plugins/spark/v3.5/spark/NOTICE Outdated Show resolved Hide resolved

synch NOTICE with main

f9dfb91

flyrain reviewed Jun 26, 2025

View reviewed changes

flyrain approved these changes Jun 27, 2025

View reviewed changes

github-project-automation bot moved this from PRs In Progress to Ready to merge in Basic Kanban Board Jun 27, 2025

flyrain merged commit 9ff2ca1 into apache:main Jun 27, 2025
11 checks passed

github-project-automation bot moved this from Ready to merge to Done in Basic Kanban Board Jun 27, 2025

fabio-rizzo-01 deleted the feature/immutability-772 branch July 29, 2025 13:14

Mutable objects used for immutable values #772 #1596

Mutable objects used for immutable values #772 #1596

Uh oh!

Conversation

fabio-rizzo-01 commented May 15, 2025

Uh oh!

snazy commented May 15, 2025

Uh oh!

pingtimeout commented May 15, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

singhpk234 commented May 15, 2025

Uh oh!

fabio-rizzo-01 commented May 15, 2025

Uh oh!

eric-maynard commented May 15, 2025

Uh oh!

fabio-rizzo-01 commented May 16, 2025

Uh oh!

eric-maynard commented May 16, 2025

Uh oh!

fabio-rizzo-01 commented May 19, 2025

Uh oh!

snazy commented May 19, 2025

Uh oh!

fabio-rizzo-01 commented May 19, 2025

Uh oh!

fabio-rizzo-01 commented Jun 10, 2025

Uh oh!

flyrain commented Jun 12, 2025

Uh oh!

Uh oh!

flyrain left a comment

Choose a reason for hiding this comment

Uh oh!

flyrain Jun 26, 2025

Choose a reason for hiding this comment

Uh oh!

flyrain Jun 26, 2025

Choose a reason for hiding this comment

Uh oh!

fabio-rizzo-01 commented Jun 27, 2025

Uh oh!

Uh oh!

flyrain commented Jun 27, 2025

Uh oh!

brooklynrob commented Jun 27, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

10 participants

pingtimeout commented May 15, 2025 •

edited

Loading