-
Notifications
You must be signed in to change notification settings - Fork 44
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
feat: Add collection response information on creation #1499
Conversation
Codecov Report
@@ Coverage Diff @@
## develop #1499 +/- ##
===========================================
+ Coverage 72.14% 72.22% +0.07%
===========================================
Files 185 185
Lines 18271 18263 -8
===========================================
+ Hits 13182 13190 +8
+ Misses 4048 4035 -13
+ Partials 1041 1038 -3
|
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 like this change a lot, thanks John. One question inline RE some http stuff.
sendJSON( | ||
req.Context(), | ||
rw, | ||
simpleDataResponse("result", "success"), | ||
simpleDataResponse("result", "success", "collections", colResp), |
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.
question: Do we still want to return "result", "success"
? Do we do this for all successful calls across the http api?
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.
Yeah, I had a similar thought. Its a somewhat meaningless item to include, but I have no strong preference either way.
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 wasn't meaningless when there was nothing else we were returning but now I think we can safely remove it.
"result": "success", | ||
"collections": []any{ | ||
map[string]any{ | ||
"name": "user", |
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.
lol: 🤣 we still have a lowercase GQL type.
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.
lol - we have a lot, I think the entire query/simple
directory, and the P2P tests are largely still uppercase.
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.
yeah not sure why those didn't get picked up. The api
folder make sense, def spaced that. But the query/simple
types are perplexing xD
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 have +1000 tests atm, would have been amazing if you/Orpheus managed to get all of them lol
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 all the cid related ones are done, others are easy to change as/when spotted
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.
Thanks, is a nice change for users.
8aa317a
to
cc00c22
Compare
…1499) Updates the response of the CLI, HTTP, and client APIs to include collection information on schema add/creation. Internally this is to just return the newly made collection descriptions. Externally this updates the HTTP API to include a `collections` key with an array of objects that include `name` and `id` values. Corresponding CLI changes to read new HTTP response state was also made.
Relevant issue(s)
Resolves #1498
Description
Updates the response of the CLI, HTTP, and client APIs to include collection information on schema add/creation.
Internally this is to just return the newly made collection descriptions. Externally this updates the HTTP API to include a
collections
key with an array of objects that includename
andid
values.Coorresponding CLI changes to read new HTTP response state was also made.
I don't know if we want this to land for 0.5.1 as in my opinion its technically a feature, more than a refactor, and we're aiming to not have features in the 0.X.1 releases. I'm happy either way.Tasks
How has this been tested?
Manually via the CLI and HTTP, CI
Specify the platform(s) on which this was tested: