Fix search_content doing repeated blocking queries to /type/ #111
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The search_content method wants to know the server's supported content types so that it can validate requested type IDs, or set defaults if the caller didn't request any specific type. The way this was implemented had a couple of related minor issues: - there was no caching of types, so every call to search_content would have to do an additional call to /types/ ; this means code doing repeated search_content calls ends up doing 1.5..2x as many HTTP requests as needed (depending on the content type). - the handling of type_ids was written in a blocking style, which is inconsistent with the rest of the API aiming to support a non-blocking style with all operations being asynchronous. This commit fixes the above issues for a modest performance improvement in some cases.
negillett
approved these changes
Aug 24, 2021
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The search_content method wants to know the server's supported content
types so that it can validate requested type IDs, or set defaults if the
caller didn't request any specific type.
The way this was implemented had a couple of related minor issues:
there was no caching of types, so every call to search_content would
have to do an additional call to /types/ ; this means code doing
repeated search_content calls ends up doing 1.5..2x as many HTTP
requests as needed (depending on the content type).
the handling of type_ids was written in a blocking style, which is
inconsistent with the rest of the API aiming to support a non-blocking
style with all operations being asynchronous.
This commit fixes the above issues for a modest performance improvement
in some cases.