vaticle / typeql

TypeQL: the polymorphic query language of TypeDB
https://typedb.com
Mozilla Public License 2.0
213 stars 45 forks source link

Add an ability to query rules from a schema #267

Open izmalk opened 1 year ago

izmalk commented 1 year ago

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

izmalk commented 1 year ago

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()

mathieuisabel commented 1 year ago

@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 commented 1 year ago

@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?

flyingsilverfin commented 1 year ago

I think @mathieuisabel is talking about showing the schema-level rule interaction graph, not the exact data-layer explanations, right?

mathieuisabel commented 1 year ago

That would be correct @flyingsilverfin . Here's probably a poor example that might give an idea:

image

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.

izmalk commented 1 year ago

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?

mathieuisabel commented 1 year ago

@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 commented 1 year ago

@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.

flyingsilverfin commented 1 year ago

Related to https://github.com/vaticle/typedb/issues/3281