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! > > > > > > > > > > > > > > > > > > > >
