You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Mar 18, 2019. It is now read-only.
Repository navigation
This repository was archived by the owner on Mar 18, 2019. It is now read-only.
Thanks for the rest_framework and the core-api library. It's exactly what I need; but I'm pretty sure I've bumped into a core-api bug. Wrote up this stackoverflow post about it.
Would be most grateful to figure out a way through this.
Okay, so if anything we should be erroring if there are two parameters with the same name. (rather than forcing the path one to take precedence) Perhaps REST framework's schema generation needs a fix here? Shouldn't cid be read-only in the serializer, and would that fix the issue?
Shouldn't cid be read-only in the serializer, and would that fix the issue?
I suppose partly, but when creating a new record, the cid field must be writable. Updating can be read-only. The cid field shouldn't be changed after creation. (Perhaps I should have named the field guid which would've been a more standard abbreviation. cid = Canonical ID)
There is a related issue when query parameters and form parameters have the same name, which might happen if one has a resource where the query parameters filter on fields of the object. In this case it seems natural to have two parameters with the same name.
One solution for _get_params() might be to loop through the fields and populate values from the params, where available, and then to deal with the parameters that didn't match to any fields. This would allow matching a param to multiple fields. Currently _get_params() loops through params and matches to just one field.
Any update on this? Running into the same issue as @ryanolf described above. Having a query and form parameter with the same name leads to dropping the query parameter.
Personally I'm not making further changes to the project, since my focus is elsewhere.
It's not dead, it's just I'm not putting more work into it from its current state.
Having a query and form parameter with the same name leads to dropping the query parameter.
it's just I'm not putting more work into it from its current state.
A project where the owner makes no more changes and accepts no more PRs is dead.
Thank you for the project, @tomchristie. The point I'm trying to raise is that it's not at all easy to discern that the project is no longer the focus of your energies and that you've moved to on to focus on other projects. I have no quarrel with that.
I'm only trying to raise awareness to other developers who rely on this project, as I once did, that they shouldn't expect changes.
Again, I would ask that you announce the project's status on the Read Me. Whether you call it deprecated, dead or EOL, I don't care. But let folks know in a prominent location.
Thanks for bringing this up! And thanks @tomchristie for all the good work, really enjoyed this. Is there a good alternative project you can recommend?
Activity
crgwbr commentedon Jul 17, 2017
Any updates on this? I'm being hit by the same issue. Can #138 be merged and released anytime soon?
thinkwelltwd commentedon Oct 6, 2017
A polite tap-tap, @tomchristie. Would it be possible to get your eyeballs on this issue, and perhaps merge #138?
lovelydinosaur commentedon Jan 30, 2018
Okay, so if anything we should be erroring if there are two parameters with the same name. (rather than forcing the path one to take precedence) Perhaps REST framework's schema generation needs a fix here? Shouldn't cid be read-only in the serializer, and would that fix the issue?
thinkwelltwd commentedon Jan 30, 2018
I suppose partly, but when creating a new record, the
cidfield must be writable. Updating can be read-only. Thecidfield shouldn't be changed after creation. (Perhaps I should have named the fieldguidwhich would've been a more standard abbreviation.cid= Canonical ID)FWIW, I'm also using AllowPUTAsCreateMixin.
ryanolf commentedon Mar 28, 2018
There is a related issue when query parameters and form parameters have the same name, which might happen if one has a resource where the query parameters filter on fields of the object. In this case it seems natural to have two parameters with the same name.
One solution for _get_params() might be to loop through the fields and populate values from the params, where available, and then to deal with the parameters that didn't match to any fields. This would allow matching a param to multiple fields. Currently _get_params() loops through params and matches to just one field.
smn-snkl commentedon Nov 19, 2018
Any update on this? Running into the same issue as @ryanolf described above. Having a query and form parameter with the same name leads to dropping the query parameter.
thinkwelltwd commentedon Nov 19, 2018
Per @tomchristie, this project is dead. I wish he'd communicate better about it.
lovelydinosaur commentedon Nov 20, 2018
Personally I'm not making further changes to the project, since my focus is elsewhere.
It's not dead, it's just I'm not putting more work into it from its current state.
Probably don't do that.
thinkwelltwd commentedon Nov 20, 2018
Current functionality will continue to work, yes.
A project where the owner makes no more changes and accepts no more PRs is dead.
Thank you for the project, @tomchristie. The point I'm trying to raise is that it's not at all easy to discern that the project is no longer the focus of your energies and that you've moved to on to focus on other projects. I have no quarrel with that.
I'm only trying to raise awareness to other developers who rely on this project, as I once did, that they shouldn't expect changes.
Again, I would ask that you announce the project's status on the Read Me. Whether you call it deprecated, dead or EOL, I don't care. But let folks know in a prominent location.
smn-snkl commentedon Nov 22, 2018
Thanks for bringing this up! And thanks @tomchristie for all the good work, really enjoyed this. Is there a good alternative project you can recommend?
lovelydinosaur commentedon Nov 22, 2018
API Star is the evolution of this project: https://github.com/encode/apistar
The client library http://docs.apistar.com/client-library/ is OpenAPI driven, which is what's become the standard.