Hi All, Introducing a dedicated pluggable interface for constructing PolarisStorageConfigurationInfo proved too intrusive at this point.
Instead, I attempted [2437] to refactor the call paths leading to PolarisStorageIntegrationProvider to push the whole entity down. This is a less intrusive change, I believe, and at the same time it allows some more flexibility for custom PolarisStorageIntegrationProvider implementations. Polaris core keeps managing the setting and extraction of PolarisStorageConfigurationInfo on call paths that do not involve loading a storage integration object. I suppose we can revisit the idea of a first-class plugin point for constructing and validating PolarisStorageConfigurationInfo instances at some later time. WDYT? [2437] https://github.com/apache/polaris/pull/2437 Thanks, Dmitri. On Mon, Aug 18, 2025 at 12:08 PM Dmitri Bourlatchkov <di...@apache.org> wrote: > Hi All, > > Currently Polaris core code has a very specific mechanism for > extracting PolarisStorageConfigurationInfo from entities. The config value > is then passed to a PolarisStorageIntegrationProvider. > > Now, PolarisStorageIntegrationProvider is pluggable and works with the > config extracted from entities by Polaris core. I am proposing to add > another integration point that would handle the construction > of PolarisStorageConfigurationInfo and work in conjunction > with PolarisStorageIntegrationProvider. Having both of these actions > customizable is intended to allow more flexibility (and better code > alignment) in handling storage integrations in downstream projects. > > I'm working on a PR to provide a concrete suggestion. > > Sending this email to proactively ask if there are any concerns with this > approach. > > WDYT? > > Thanks, > Dmitri. > > >
