hi there. i have a schema like this. nodes are linked one to another, each link belongs to customer, but when browsing, one customer can have access to other customer links:
_:A <link_customer1> _:B .
_:A <link_customer2> _:B .
_:A <link_customer1> _:C .
_:A <link_customer3> _: D .
for example, i need to count for A node all distinct outcoming nodes with link_customer1 link and link_customer2 predicates only. so, result should be 2 (B and C).
it works with storing all predicates in one and adding a “customers” facet, so query would be like:
nodes_count as count(link @facets(anyofterms(customers, “customer1 customer2”))
but as i understand this solution is quite bad for sharding due to using one predicate for all customers.
I believe that this is the only way. Other mathematical parameters only work with variables. But count is perfect for what you want. If there are repeated UIDs it returns only unique values.
The form count(uid) counts the number of UIDs matched in the enclosing block.
We moved toward using many separate predicates for sharding purposes but pay the price in cumbersome queries. For example if I want to retrieve all predicate values that are a “name” but there are 100 different “name” predicates, we have to list all 100 predicates in the query. What we need is a higher level grouping of predicates so that we get sharding efficiency without sacrificing query conciseness.
The way we get around this is by storing these groupings ourselves and using server side string building to build the queries…Because it’s not practical to write these queries by hand.