-
Notifications
You must be signed in to change notification settings - Fork 11
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
Update docs #507
base: main
Are you sure you want to change the base?
Update docs #507
Conversation
Signed-off-by: Gabriel Indik <[email protected]>
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 seems the documentation here is generated, so I’m wondering if it’s necessary to add anything manually.
Regarding the fields, it looks like the, for example, the bidx_queryIndexedBlocks
function receives the query object generated by the script. Could you help me understand why specific fields are being written for the query? Are there any restrictions from the API that require this?
For the changes in queryjson.md
, it seems there might be a small issue with how the docs are being generated. Would it make sense to address this through the docs generator script instead of making manual updates?
@dwertent I'll look into the generation portion you pointed out. With regards to the fields and their types, that's exactly where the documentation was falling short. The query it accepts will support only a specific set of fields with a specific set of types per API call. |
Signed-off-by: Gabriel Indik <[email protected]>
@dwertent thank you for the heads up, you are absolutely right, that portion of the docs is generated so making the changes to the markdown is not the right approach. I modified the Go code that generates the file that contained the main issues (wrong nesting of the values for the queries). When it comes to adding the tables, that will likely require some additional work. I was looking at how reflection is being used to extract all the information into the docs (which is brilliant) but for the case of the specific fields available in each query (and their types) those are defined as variables in other packages and not directly referenced by the methods. So this will require a bit more investigation. I will be creating a separate issue for those. |
The QueryJSON section in the docs contained examples that are not valid. Specifically, nested value objects. This PR addresses that issue and in addition it incorporates the available fields and their types to various queries in the APIs section.
These are included in the form of a table. Example: