Conversation
As discussed in apache#1894, `catalogConfigUnsafe()` has a use case in the main codebase - that is to support gradual migration to new property names. Using legacy names in runtime already leads to a user-face WARN log message. Support for those legacy property names is to be dropped in 2.0.
If that's true, wouldn't we also drop the method |
|
I removed |
I'd expect that we may want to rename other properties as the project matures... |
|
catalogConfigUnsafe is specific to properties that don’t start with the
polaris prefix and are therefore unregistered. I believe there’s an assert
for this and the Javadoc details the same. So there should be no new usage
as long as we don’t introduce any more unsafe configs. If we migrate other
config names, we would so through a different mechanism that preserves the
registration of both names.
…On Fri, Jun 27, 2025 at 3:28 PM Dmitri Bourlatchkov < ***@***.***> wrote:
*dimas-b* left a comment (apache/polaris#1970)
<#1970 (comment)>
[...] isn't it fair to say the method is marked as deprecated for removal
in 2.0?
I'd expect that we may want to rename other properties as the project
matures... catalogConfigUnsafe() might still be useful after 2.0.
—
Reply to this email directly, view it on GitHub
<#1970 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AFRE3SCAW5AZO4JDLNVCSGT3FXARVAVCNFSM6AAAAACAJ6WGOOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTAMJUGQ4TOOBYG4>
.
You are receiving this because your review was requested.Message ID:
***@***.***>
|
|
I see your point now @eric-maynard . In this case, I believe changes in #1894 are actually correct (no need to span build logs with warnings about known calls to |
|
Cf. #1974 |
As discussed in #1894,
catalogConfigUnsafe()has a use case in the main codebase - that is to support gradual migration to new property names.Using legacy names in runtime already leads to a user-face WARN log message.