Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve model for namespace #159

Open
eikek opened this issue Jun 19, 2024 · 0 comments
Open

Improve model for namespace #159

eikek opened this issue Jun 19, 2024 · 0 comments

Comments

@eikek
Copy link
Member

eikek commented Jun 19, 2024

As described in #154 , currently our solr documents have one single property namespace denoting two different things.

For User and Group entities, the namespace porperty defines the namespace. Users and groups share a common namespace for their handles. Then a Project is defined inside a namespace - belonging either to a group or user. The Project uses for "defined inside that namespace" the same namespace property.

This means that when developing the difference must be known and taken care of implicitly. It also can make efficient searching hard to implement, if (as in #154) for some results sub-queries should be run based on only one of the meanings. Currently to resolve namespaces for projects, we resolve also the namespaces of users and groups to itself, that will result in potentially returning a lot of data from SOLR that we just ignore. It is obviously better to not ask for it in the first place.

Therefore, I think it is better to distinguish these two things more clearly. For example, by introducing another property on the project in_namespace or similar. And then remove the namespace property on projects.

The user query can be easily adopted to retain the ambiguity, but sub queries for resolving namespace details can be optimized. It will make it easier/clearer when adding more namespace-d entities later.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant