query method for store API
#311
Conversation
Codecov ReportPatch coverage:
Additional details and impacted files@@ Coverage Diff @@
## main #311 +/- ##
==========================================
- Coverage 89.29% 88.55% -0.75%
==========================================
Files 68 70 +2
Lines 5027 5661 +634
==========================================
+ Hits 4489 5013 +524
- Misses 538 648 +110
... and 5 files with indirect coverage changes Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. ☔ View full report in Codecov by Sentry. |
adzialocha
changed the title
find and findMany queriesquery method
adzialocha
changed the title
query methodquery method for store API
…cted fields, fix pagination via list index
There was a problem hiding this comment.
Hey! Still boggles my mind how much functionality these recent PRs introduces, and this is really the heart of it 👍 it totally feels like AbstractQuery and all the parsing into SQL strings could be a whole crate with structs and traits for implementing similar search patterns with other data sets. In another life I suppose 😄
Mostly I had just clarification requests and small corrections. There's one thing about the count query I'd like clearing up though.
Great work!
| } | ||
| } | ||
|
|
||
| fn where_filter_sql(filter: &Filter, schema: &Schema) -> String { |
There was a problem hiding this comment.
Comments on these methods are nice, even though they "do what they say"
aquadoggo/src/db/stores/query.rs
Outdated
|
|
||
| let rows_per_document = std::cmp::max(fields.len(), 1); | ||
|
|
||
| for (index, row) in rows.into_iter().enumerate() { |
There was a problem hiding this comment.
Does this work because both the rows and fields are sorted by document_view_id?
There was a problem hiding this comment.
Exactly! I'll verify that again as I did some changes recently which might affect this
…ot queries without selected fields
This PR implements the "backend" for our new "Query" API to paginate, filter and sort collections based off the work in #302 and #308. Specifically this involves designing the SQL query which gets the data from the database, to then return it back to the GraphQL API consumer.
The SQL query is fairly complex as it a) is based on our "operation-graph-like" table structure and b) covers a lot of features. The goal is to only make one SQL query per API request. No index optimizations took place yet, this requires some heavy-load testing and benchmarking (just setting arbitrary indexes can worsen performance).
Todo
endCursorin pagination info responseDocumentCursorfrom the scalar typeCursorScalarin the GraphQL API, sticking to the separation of concerns we already have introduced in all other placesFilterstruct to overwrite previously set boolean filters to allow users to override that defaultNext Steps
editedin GraphQLmetaAPIdeletedin GraphQLmetaAPIorderBy)Closes: #310
📋 Checklist
CHANGELOG.md