-
Notifications
You must be signed in to change notification settings - Fork 20
Add analyze BDD #381
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add analyze BDD #381
Conversation
73e2242 to
3614fd9
Compare
8f2975a to
82439ce
Compare
|
|
||
| Scenario: Errors in the query are returned as errors | ||
| Given connection open read transaction for database: typedb | ||
| When typeql analyze query; parsing fails |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think Cole's commentary is reflecting something accurate: analyze() shouldn't throw an error, but it should return an error. I think we do unify this in the service layer anyway right? So this could be generically "fails with message containing..."?
| [thing([person])], | ||
| stream([thing([name])]), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looks gud
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if we introduce polymorphic/inferred function argument annotations this will also work nicely
| """ | ||
| { | ||
| name: [string], | ||
| ref: [integer] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Im guessing these are all representing optionals right? Eg could be name-string or missing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, that's still a list of types. I haven't actually considered optionals because type-inference doesn't either.
It's not even returned by the analyze endpoint.
| """ | ||
| Pipeline([ | ||
| Match([ | ||
| Isa($p, person), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would match the 'Annotations' to call this 'Trunk' (though my other comment suggests "And" or "Constraints" or "Statements"!)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We encode Or, Not, Try as constraints, so here we don't need that.
flyingsilverfin
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Approved, but please do check the 1 naming change before merging anything!
## Product change and motivation Tests the query structure returned by the analyze endpoint (and used by studios' graph visualizer) ## Implementation * Implements steps & functor encoding used in typedb/typedb-behaviour#381 * Small fixes around.
Usage and product changes
Adds test for the query structure and annotations returned by the analyze endpoint