Hi all, Thank you for the suggestion to investigate ACCEPT_CASE_INSENSITIVE_ENUMS however, I came to the conclusion that it would not work because storageType in particular (Not sure about other enums) is bound to a type and not a simple enum. So the approach that could work would be to have a custom TypeIdResolver, however this will have to be done on a case by case basis which is something that we do not desire. We could definitely make the change more hostlically at spec level but I have hard times reasoning about the safety aspects of the change mostly because it seems to have a much larger blast radius. It is also not clear to me if we would intentionally break any of Polaris dependencies.
On Wed, Jan 7, 2026 at 4:07 AM Robert Stupp <[email protected]> wrote: > Yes, Jackson has a feature toggle for this behavior. > > The breaking change would happen, as a newer client would break > against an older server using the same spec version. > > Technically we have a lot of mapper instances floating around in > Polaris, in production and even more in test code. > > The bigger issue is that the same (relevant) mapper instances are also > used for other APIs like the Iceberg one. > > On Wed, Jan 7, 2026 at 11:43 AM Alexandre Dutra <[email protected]> wrote: > > > > Hi all, > > > > First off, thank you, Innocent, for the recent PR [3349]! > > > > I've reviewed it and noted that it specifically special-cases the > > StorageConfigInfo enum for deserialization. Drawing on the discussion > > in [996], I believe we should adopt a more consistent approach: either > > all enums should be deserialized in a case-insensitive manner, or none > > should. Special-casing StorageConfigInfo feels unnecessarily > > complicated. > > > > I therefore recommend we investigate using Jackson's > > ACCEPT_CASE_INSENSITIVE_ENUMS Mapper feature [1] as a cleaner, more > > consistent solution. > > > > Regarding the REST API: I am questioning whether this change would be > > a breaking one. Existing clients should continue to function as > > expected. The only potential failure scenario I can imagine is a > > client intentionally sending an incorrect enum name and relying on it > > to fail, which seems unlikely. Therefore, a formal REST API > > specification change may not be necessary. What do others think? > > > > Thanks, > > Alex > > > > [1]: > https://www.javadoc.io/doc/com.fasterxml.jackson.core/jackson-databind/latest/com/fasterxml/jackson/databind/MapperFeature.html#ACCEPT_CASE_INSENSITIVE_ENUMS > > [996]: https://github.com/apache/polaris/issues/996 > > [3349]: https://github.com/apache/polaris/pull/3349 > > > > On Tue, Jan 6, 2026 at 9:30 PM Dmitri Bourlatchkov > > <[email protected]> wrote: > > > > > > Hi Innocent, > > > > > > The most formal evolution doc we have is this: > > > https://polaris.apache.org/in-dev/unreleased/evolution/ > > > > > > There is no working group. API changes are simply expected to be > discussed > > > on `dev`. > > > > > > Cheers, > > > Dmitri. > > > > > > On Tue, Jan 6, 2026 at 3:25 PM Innocent Djiofack <[email protected] > > > > > wrote: > > > > > > > Hello Robert, > > > > > > > > I agree with your point that, strictly speaking, this would be a > breaking > > > > REST API change. If the case-insensitivity is baked into a future API > > > > specification, it would eliminate the need for additional logic to > handle > > > > it elsewhere. > > > > > > > > I have a question about the API evolution process: > > > > > > > > - How is the API evolved? > > > > - Is there a specific working group dedicated to API changes? > > > > - Does this process follow a predefined cadence? > > > > > > > > If we decide to go this route, it would be helpful to ensure this > change is > > > > on the radar of the right people so it does not get overlooked. > > > > > > > > Best regards, > > > > Innocent > > > > > > > > On Tue, Jan 6, 2026 at 4:18 AM Robert Stupp <[email protected]> wrote: > > > > > > > > > Hi all, > > > > > > > > > > Thanks for taking a stab on this issue and the constructive > discussion! > > > > > > > > > > Very strictly speaking this would be a breaking REST API change. > > > > > I propose to consider making those technical identifiers > > > > > case-insensitive in a future version of the REST API. > > > > > > > > > > Robert > > > > > > > > > > On Mon, Jan 5, 2026 at 6:32 PM Innocent Djiofack < > [email protected]> > > > > > wrote: > > > > > > > > > > > > Hello Dmitri, > > > > > > > > > > > > Thanks for your prompt reply. > > > > > > > > > > > > I understand your point about the added complexity in JSON > > > > serialization > > > > > > and agree that, from a user perspective, it is not a major > hindrance to > > > > > > productivity. I am comfortable with either outcome and will be > happy to > > > > > > follow the direction the community decides to take on this issue. > > > > > > > > > > > > Best regards, > > > > > > Innocent > > > > > > > > > > > > On Mon, Jan 5, 2026 at 10:20 AM Dmitri Bourlatchkov < > [email protected]> > > > > > > wrote: > > > > > > > > > > > > > Hi Innocent, > > > > > > > > > > > > > > I appreciate your involvement in this project and your > contribution > > > > > towards > > > > > > > [996]! > > > > > > > > > > > > > > You PR [3349] looks correct and concise. > > > > > > > > > > > > > > However, it does introduce extra complexity into the > serialization of > > > > > > > Polaris data over JSON. Given that the case insensitivity > consents in > > > > > [996] > > > > > > > are about technical type IDs, I personally do not think adding > > > > > complexity > > > > > > > in JSON (de-)serialization in this case is worth the feature. > > > > > > > > > > > > > > Assuming existing error messages on type name mismatches are > clear, I > > > > > think > > > > > > > it should be fairly straight-forward for clients / users to > use upper > > > > > case > > > > > > > type IDs. > > > > > > > > > > > > > > If other people think that having case insensitive type IDs is > still > > > > > worth > > > > > > > the extra code complexity, PR [3349] looks good to me from the > > > > > technical > > > > > > > perspective. > > > > > > > > > > > > > > [996] https://github.com/apache/polaris/issues/996 > > > > > > > > > > > > > > [3349] https://github.com/apache/polaris/pull/3349 > > > > > > > > > > > > > > Cheers, > > > > > > > Dmitri. > > > > > > > > > > > > > > On Fri, Jan 2, 2026 at 12:50 AM Innocent Djiofack < > > > > > [email protected]> > > > > > > > wrote: > > > > > > > > > > > > > > > Hello, > > > > > > > > My name is Innocent. I am a new apache Polaris user who is > strongly > > > > > > > > interested in contributing to the code base. I have been > looking at > > > > > #996 > > > > > > > > <https://github.com/apache/polaris/issues/996> and given > the back > > > > > and > > > > > > > > forth > > > > > > > > on the issue as well as the guidance from Dmitry, I thought > it > > > > would > > > > > be a > > > > > > > > good idea to start this thread to align on what should be > done. > > > > > > > > > > > > > > > > As a quick refresher, the issue is that storage type is not > case > > > > > > > sensitive. > > > > > > > > Attempting to create catalogs with storage type different > `file` > > > > > instead > > > > > > > of > > > > > > > > `FILE` or `s3` instead of `S3` will fail. Other operations > > > > requiring > > > > > the > > > > > > > > storage type will also fail. On the user side, once the > issue is > > > > > > > detected > > > > > > > > it is generally quite easy to fix. However, user experience > will be > > > > > much > > > > > > > > improved if users don't have to worry about such details, so > I > > > > think > > > > > > > making > > > > > > > > storage type case insensitive would be an improvement. > > > > > > > > > > > > > > > > Before I get into how we would want to do it, I would like to > > > > gather > > > > > > > > opinions on the matter before I invest more time into > looking at > > > > how > > > > > the > > > > > > > > change would look like. > > > > > > > > > > > > > > > > Thank you for having me in the community! > > > > > > > > > > > > > > > > > > > > > > > > >
