Hello, Kirill. I like the idea of describing in docs and code lifecycle of UDF (and any other entity). But, lifecycle of UDFs is not clear for me.
Can you, please, describe it more clearly? Can we put it in IEP or just a wiki page to save knowledge for the future. пт, 2 окт. 2026 г. в 16:41, ткаленко кирилл <[email protected]>: > > Hi everyone, > > I'd like to discuss the lifecycle of UDF and UDTF registered through > CacheConfiguration#setSqlFunctionClasses. > > Currently, functions are registered in the cache's SQL schema, but their > lifecycle appears inconsistent. > When a cache is destroyed, its functions disappear if the schema itself is > removed. > However, if the schema remains for example, PUBLIC or a schema shared with > another cache the functions remain registered. > > There is no explicit API to unregister these functions. > As a result, destroying and recreating a cache does not reliably allow users > to re-register its functions in a running cluster. > > I propose tying these registrations to the lifecycle of the cache that > introduced them: > when a cache is destroyed, its UDFs and UDTFs should also be removed from the > SQL schema, even if the schema remains. > Functions registered by other caches, including other overloads, should > remain unaffected. > > We should also document explicitly that these functions belong to the cache's > SQL schema and that their registrations are removed when the owning cache is > destroyed. > Does this approach make sense? > If you think functions should have a lifecycle independent of caches, what > alternative would you suggest for unregistering and re-registering them in a > running cluster?
