-
Notifications
You must be signed in to change notification settings - Fork 4
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
Call current user API v1/user
during sdk client initialization.
#33
Closed
Closed
Changes from all commits
Commits
Show all changes
9 commits
Select commit
Hold shift + click to select a range
61cb261
Call current user API `v1/user` during sdk client initialization.
dbkegley 2460459
Merge branch 'main' of github.com:posit-dev/posit-sdk-py into kegs/cu…
dbkegley fdc7913
Always call users api
dbkegley 3d35dbc
Fix client tests
dbkegley ecb0e8d
Remove endpoints.py and tests
dbkegley 89b7afc
merge: resolves conflicts (#40)
tdstein 8c5beb9
Merge remote-tracking branch 'origin/main' into kegs/current-user
tdstein 59f1c75
Merge branch 'main' into kegs/current-user
tdstein 3246cc3
fix: url resolution
tdstein File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
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
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
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
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
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
Oops, something went wrong.
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.
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.
Do we want to instantiate a new instance every time? The Users class is designed to fetch from the server once, and then use cached results for subsequent iterations.
There are pros and cons to fetching from the server every time.
We currently don't have any methods that mutate the server, but when we do, my thought is to invalidate the cache on methods that mutate (post, delete, put). This would trigger a fresh fetch on the next iteration.
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.
Also, passing
self
toUsers
instead of thesession
andconfig
seems odd. This makesclient.users.client.users.client.users
validIf the goal is to reduce the boilerplate of passing two variables down to one, I would prefer creating a DTO object that wraps
session
andconfig.
But, I still think that is overkill at this stage.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 instantiating from
Client
every time gives you the behavior you want. If you (the SDK user) want to use the cached results, do something likeall_users = client.users.find()
and work withall_users
as much as you want. But some actions you'll want to do will modify the collection on the server, and you'll want a way to refresh. So then you go toclient.users
again.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.
True, but IME it's useful to be able to get back to the original connection object from wherever you are in the API.
Isn't
Client
already the object that wrapssession
andconfig
?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 don't really have any strong opinion about how this happens. My only requirement at this stage is that there is some way to get information about the currently authenticated user from the
v1/user
endpoint. I need this information to be available in theOAuthIntegration
Resource.I'm fine with changing to approach to use DI instead if that's preferred. For example:
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.
session
holds the connection here.Yes, but circular references should generally be avoided.