You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As a somehow extraneous feature of #2599, I am moving the "virtual" namespace (i.e. real namespace + arbitrary number of "sub-namespaces", dot-separated) resolution out of NamespaceService#resolveWorkspaceIdForNamespace and centralizing it in the in-memory, request-scoped NamespaceRequestCache (which is used by the service and a few more).
This way, the resolution can be used in one point from nearly anywhere in the code base (which also allows removing the same identical logic from the UserNamespaceRoleService - since it uses the cache too).
To develop this further on and optimize on a few CPU cycles / stack entries, the idea would be to map the resolved real namespace by virtual namepace name in a new concurrent map in the cache.
That would require moving the recursive logic in another method that retains the "root" virtual namespace name and queries the map with it / puts it in once resolved.
This is a minor/trivial task but given the volume of resolution requests when dealing with a model in a sub-namespace, it is worth implementing soon.
The text was updated successfully, but these errors were encountered:
As a somehow extraneous feature of #2599, I am moving the "virtual" namespace (i.e. real namespace + arbitrary number of "sub-namespaces", dot-separated) resolution out of
NamespaceService#resolveWorkspaceIdForNamespace
and centralizing it in the in-memory, request-scopedNamespaceRequestCache
(which is used by the service and a few more).This way, the resolution can be used in one point from nearly anywhere in the code base (which also allows removing the same identical logic from the
UserNamespaceRoleService
- since it uses the cache too).To develop this further on and optimize on a few CPU cycles / stack entries, the idea would be to map the resolved real namespace by virtual namepace name in a new concurrent map in the cache.
That would require moving the recursive logic in another method that retains the "root" virtual namespace name and queries the map with it / puts it in once resolved.
This is a minor/trivial task but given the volume of resolution requests when dealing with a model in a sub-namespace, it is worth implementing soon.
The text was updated successfully, but these errors were encountered: