-
Notifications
You must be signed in to change notification settings - Fork 20
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
FuelClient API expects redundant possibly conflicting information #46
Comments
Original comment by Louise Poubel (Bitbucket: chapulina, GitHub: chapulina).
Yup, using ModelIdentifier::Server(), right? |
Original comment by Louise Poubel (Bitbucket: chapulina, GitHub: chapulina). See pull request #56 |
Original comment by Shane Loretz (Bitbucket: Shane Loretz, GitHub: sloretz). I think the intent was a model identifier would be sparsely populated when passed to those functions, and only models on the server that matched the populated items would be returned. The server must be specified when querying so it makes sense as it's own parameter. On the output side, when working with a bunch of fetched models each has an identifier that says what server it came from. Maybe ModelIdentifier has too much responsibility. The job of specifying parameters to query could be separated from the job of describing the parameters of a fetched model. |
Original comment by Louise Poubel (Bitbucket: chapulina, GitHub: chapulina). I see, yes, perhaps decoupling query params from response params would make things clearer. It's worth pointing out that the I'm fine either keeping the sever parameters or removing them, but if we're keeping them, we should at a minimum document which one is the authoritative in case |
Original comment by Louise Poubel (Bitbucket: chapulina, GitHub: chapulina). pull request #56 has been merged, I'll work on a PR to default deprecating the functions |
Original report (archived issue) by Louise Poubel (Bitbucket: chapulina, GitHub: chapulina).
Several functions on
FuelClient
accept both aServerConfig
and aModelIdentifier
.But considering that
ModelIdentifier
keeps its ownServer
config, we may need to handle the situation when these two conflict. What's the motivation for passingServerConfig
?If there's no special need for passing
ServerConfig
, I suggest we stop using it in version 1, document that it has no effect, and deprecate it on version 2.The text was updated successfully, but these errors were encountered: