Best way to set global filters?

[ChrisZ32]

I'm new to graph databases but trying to think through how Cosmos DB and Gremlinq could work for us.

Background to the problem:

Most of our data is multi-tenanted and I need a good way of limiting what data is returned when queries are run. In EF Core using SQL we use global query filters. These filters add to all (or create if necessary) SQL WHERE clauses for SELECTs so that we only use and return entities with a certain TenantId. The value for the filter is determined per-query at runtime. We do this so that it is virtually impossible (well, very difficult at least) for our developers to mess up multi-tenancy.

I would like to store our multi-tenanted data alongside our un-tenanted data inside the same graph if possible as we have use-cases for querying the the links between un-tenanted and tenanted data - so I'm trying to avoid using a separate database for each tenants data.

Question:

What is the best way to apply global filters to every Gremlinq query to limit what vertices are returned?

Investigative steps taken:

I have played around with the TransformQuery method available in ConfigureExecutor to see if I can edit the underlying gremlin query. To my surprise (I am new to gremlin) I managed to make it work for a simple POC use-case pretty easily:

var groovyQuery = query.ToGroovy();
if (groovyQuery.Bindings.Values.All(x => !IsTenantedVertexLabel(x.ToString()))) // will only work if all vertexes are tenanted I think
    return query;

var script = groovyQuery.Script;
script = script.Replace("V()", "V().has(_xyz,_123)"); // add the TenantId filter
var bindings = groovyQuery.Bindings.ToDictionary(pair => pair.Key, pair => pair.Value); // add the new filter to the bindings
bindings.Add("_xyz", nameof(TenantedVertex.TenantId));
bindings.Add("_123", _tenantIdAccessor.GetTenantId()); // _tenantIdAccessor is a variable from the DI container and returns the current TenantId in context

var newQuery = new GroovyGremlinQuery(groovyQuery.Id, script, bindings);
return newQuery;

This is obviously extremely crude and would need a lot of work to make production ready and cover all cases, but it appears to prove my theory that it is at least possible - though It seems pretty hacky:

• The query has already been constructed by this point so I'm too late in the process really
• I'm not sure if simply adding a has(...) to every V() call I find will actually cover all cases of retrieving a vertex
• I don't know how this will affect performance

Wondering if there is a better way before I go too far down this path! Thanks :)

[danielcweber]

This is probably tackled best by a subgraph strategy, something that CosmosDb doesn't support and ExRam.Gremlinq will support in the very near future, although through a commercial extension offering (which will then work e.g. with AWS Neptune).

[ChrisZ32]

I had just seen the WithStrategy changes on the preview branch - this makes a LOT more sense, thanks!