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