Hi @Marion_Nehring and @sebawita for a great Hero Roundtable yesterday. If I seemed a bit more animated than usual, it is because I have a major deal pending whose success is riding on a certain capability I need in Weaviate being available.
It was requested here two years ago: FR: Add a `ContainsNone` operator · Issue #3513 · weaviate/weaviate · GitHub
I have discussed it previously in these threads:
I need implementation of the “ContainsNone” GraphQL operator. This will allow me to create, using my existing query properties, what I call an “Exclusion Filter”.
Why is this so important? Because it allows every Weaviate developer to implement access control over their vector stores using ONLY the GraphQL filter. I can give you the details of my particular use case in private, but in general:
Let’s say you use a class property called “Groups” to determine who can access particular pieces of content.
Public users can access Groups A, B and C. A Private organization creates content in Groups D and E that is restricted to it’s users.
A, B and C are also serve as categories, so it is possible for a single piece of content to belong to both A and D. In this very basic permissions scenario, the current GraphQL tool does not provide a way to EXCLUDE content from Public users that belongs to both Public and Private groups.
That’s where the “Exclusion Filter” comes in.
Purpose: Improves search performance by filtering out group-restricted content at the query level.
How it works:
- Receives query prompt with identified user from calling app
- Checks which groups the current user cannot view (lacks “view group” permission in calling app)
- Builds a filter query to exclude documents containing those groups in the Groups property
- Adds the filter as a ContainsNone operator: field:“GroupD” OR field:“GroupE”) to the GraphQL
Result: GraphQL returns a smaller, pre-filtered result set, reducing the number of documents that need potentially expensive permission checking.
Key benefits:
- Performance: Less data transferred from Weaviate (economical and faster)
- Efficiency: Bulk filtering at database level vs individual applications level checks
- Non-intrusive: Doesn’t change search relevance or user’s search terms
- Safe: Restricted Documents which also belong to public groups are NOT included by default
So, what can I do to get this in front of developers to make the case that this would not only help me out, but could be of great benefit to many other users seeking to control access using just the GraphQL tool?
