talksik/genqlient
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

another idea on query extraction

Browse Source
This commit is contained in:
Ben Kraft
2021-03-31 10:43:08 -07:00
committed by GitHub
parent fb3c0b3cb4
commit 291ce980b3
1 changed files with 1 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files
DESIGN.md
+1 -1
View File
@@ -277,6 +277,6 @@ This can all be configurable globally -- say you can decide whether to use conte
### Query extraction (for safelisting)
One thing we want to be able to do is to make it clear exactly what query-document (down to comments and whitespace) we will be sending in the query for the purposes of safelisting and querying based on hash. In the case where you have one query per file, that's easy, just use the whole file. But you may want to share fragments between queries, in which case this is trouble: you either need a way to include fragments from another file (and a defined concatenation order), or you need to have several queries per file, and either have genqlient extract the right parts (in a defined/reproducible way), or have it send up the full file and the operation name to use (in which case we should still encourage you to not do that unless you're hashing, so that you aren't sending up too much data). We could also allow configuration between the last two options (so if you don't care about hashing/safelisting you can auto-extract).
One thing we want to be able to do is to make it clear exactly what query-document (down to comments and whitespace) we will be sending in the query for the purposes of safelisting and querying based on hash. In the case where you have one query per file, that's easy, just use the whole file. But you may want to share fragments between queries, in which case this is trouble: you either need a way to include fragments from another file (and a defined concatenation order), or you need to have several queries per file, and either have genqlient extract the right parts (in a defined/reproducible way), or have it send up the full file and the operation name to use (in which case we should still encourage you to not do that unless you're hashing, so that you aren't sending up too much data). We could also allow configuration between the last two options (so if you don't care about hashing/safelisting you can auto-extract). A variant is to have genqlient write out a list of what it thinks the final queries will be (it has them to include in the generated code), in which case you don't have to care how smart that is.
We can decide this later once we support fragments and safelisting/hashing; it's fine if that's not available at first.