[DataQuery] New DQT backend implementation #8268
Conversation
53bf5fc to
a0d5de6
Compare
|
Needs work, not in sync with the latest updates to #8219 |
7032e29 to
bc6858a
Compare
bc6858a to
e92eaaa
Compare
This describes what is POSTed and also goes directly into a subfield of a Query object, not directly into the query.
5f73d36 to
eb85340
Compare
|
I have sent the proposed data to POST /dataquery/queries and got a 200 {"QueryID": 1} |
|
I believe the sample data in the schema.yml assumes that the candidate_parameter's QueryEngine is implemented (Done in PR#8288, as of now unmerged). It should have returned a 400 error. It looks like it accepted it because of this FIXME needing to be implemented: https://github.com/aces/Loris/pull/8268/files#diff-d21396483bc372130220b07b323e521f63ff1aca56372eb09102c3b4c19e324aR65 |
xlecours
left a comment
There was a problem hiding this comment.
This makes sense. It's hard to test until there is a frontend to it.
|
TODO: After this PR is merged make an issue about instruments module needing to separate viewing data permission from data_entry. (Currently, the |
zaliqarosli
left a comment
There was a problem hiding this comment.
Looks good! the only issue I had is the one already added by dave as a to-do above ^^
ec5434c to
baa59f1
Compare
|
@zaliqarosli @xlecours re-factored code as per Xavier's request, can you guys re-review? |
This is intended to make it easier to review/test #8219 or #8216 by implementing the swagger schema, so that it can be tested via the the api docs module.
It's blocked by #8221 and #8260. In order to have anything to query against, you probably also need #8216 (or another QueryEngine implementation for a module.)
Nonetheless, the implementation should be complete (other than the one endpoint described as aspirational in the swagger schema.) and can be reviewed. I may have broken something while trying to extract it from the branch where I was developing the frontend or while trying to appease phpcs/phan.