typeql
typeql copied to clipboard
vaticle
Add an ability to query rules from a schema
Problem to Solve
We can define/undefine rules. We can read a schema with read transactions from any client. But we can't read rules right now.
Current Workaround
TypeDB Console has a built-in function to return a full schema with rules.
Proposed Solution
Have a syntax in TypeQL to query a full schema with rules and/or rules only.
Include rules into TypeDB Studio Types browser Export schema button result or create a separate rule tool.
Additional Information
As was stated in the https://github.com/vaticle/typedb/issues/3281 (possible duplicate but in TypeDB repository), we can
Use Concept API, calling transaction.logic().getRule(label) or transaction.logic().getRules()
@izmalk Being able to query rules and see their dependencies on other rules would also be beneficial. I was talking about this with @tomassabat in the context of rules debugging where it's currently hard to assess the which rules get triggered from a particular query when there are multiple rules involved.
@izmalk Being able to query rules and see their dependencies on other rules would also be beneficial.
I'm not sure what are the dependencies on other rules. Do you mean rule interaction via inferred data?
it's currently hard to assess the which rules get triggered from a particular query when there are multiple rules involved.
But we can do that with an explanation option enabled. Did you try something like that: https://github.com/izmalk/typedb_test_queries/blob/main/all-queries.py#L176 ? It's sometimes tricky to read the conclusion part of the explanation but I can't see any better solution for now. Do you?
I think @mathieuisabel is talking about showing the schema-level rule interaction graph, not the exact data-layer explanations, right?
That would be correct @flyingsilverfin . Here's probably a poor example that might give an idea:
Also in the same line of thought for debugging purposes, I remembered James showing me at some point a visual representation of the query plan (which was pretty intense). I don't know if there's a way to see that to help troubleshooting situations where rules are getting triggered unnecessarily due to common mistakes (i.e. not constraining types correctly).
Bottom line, the end game is figuring why queries are not performing in certain situations. i.e. It's tough to assess whether the query plan is ok without manually figuring out everything the query references.
That would be correct @flyingsilverfin . Here's probably a poor example that might give an idea:
Nice. But that seems to be out of the scope of this particular issue. Can you create a separate issue?
@izmalk Just to be sure, you're referring to the query plan piece specifically for the new issue? The dependency graph would still be in scope as you would want to be able to query rules for that kind of output.
@izmalk Just to be sure, you're referring to the query plan piece specifically for the new issue? The dependency graph would still be in scope as you would want to be able to query rules for that kind of output.
I was referring to the dependency graph. While these features can be connected, even dependent on each other, I think they are different features and might have a different priority/deadline/author. The original feature only requests to be able to retrieve rules from a schema.