-
-
Notifications
You must be signed in to change notification settings - Fork 6.9k
Add SimplePathRouter #6789
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
Add SimplePathRouter #6789
Conversation
Milestoning for review. Thanks! |
It may be improved a bit if support for Django 1.x gets dropped (ie: some bad |
I'm thinking this should be pushed to the 3.11 release, as that is when we'll likely drop Django 1.11 |
@rpkilby Good call |
@rpkilby I have updated with CRUD tests and removed Django 1.11 compact. Tell me if everything is fine for you. |
7a17941
to
c4c09ef
Compare
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.
can you skip tests for Django 1.11 for this PR? dj1.11 seems to be supported for some more time.
I have also added an assertion in |
Ok... seems that |
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.
can you rebase plz?
17af0e1
to
c1348cf
Compare
Rebased. |
We've not dropped 1.11 on this pass, since its LTS. Wondering if we might just outright switch the behavior on the next release - I'd rather we didn't have two different have two different class implementations here. |
@tomchristie you are right that a single-class implementation would be better. I think that it can be done since the difference between those two are just two methods ( I will try to refactor the code to have a single class. |
When we drop 1.11 I'd actually probably be okay with us just completely switching to There's not really any great options for us here. |
b1d231f
to
4696b19
Compare
@auvipy I have rebased the branch with current master. Let me know if any other change is needed. |
the workflow need to be triggered |
I am playing around with this PR a bit, and in my case the major reason I am trying to move to I am able to make this work with the code in this PR by setting This isn't a blocker, since it seems to be working just fine, but figured it was worth bringing up while it is still in PR. If there is an alternative way to approach these custom converters, let me know, and I will give that a try too. |
@camuthig you pointed out an interesting use case. I could change the code to use an "alternative" attribute with a more readable name to solve it, but this feels quite a mock-fix IMO. Preserve backwards compatibility and handle this use case in an elegant way is a bit hard. I would like to go back to my first implementation where there were 2 base router classes: one for regex and one for path, so there is no chance of mixing code and name would be quite expressive (but the project owner clearly expressed he prefers to have a single class). The other way I see is to rework the current implementation in order to handle the choice between regex or path on a per view basis and not globally on the router, the problem here is to handle @tomchristie what do you think would fit better? |
Let us focus on the actual issue first. we are going to make the SimplRouter allowing new path based routing. should we also do the same for the DefaultRouter? |
@auvipy, do you mean this line?
Apart from that |
yeah, OK. I got commit access recently. so want to prioritize this one and draw a conclusion very soon to get this merged. of course considering all the natural edge cases are ironed out |
notes_router = SimpleRouter() | ||
notes_router.register(r'notes', NoteViewSet) | ||
|
||
notes_path_router = SimpleRouter(use_regex_path=False) |
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.
can we add another test case which use DeafultRouter please?
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 should not be a problem to replicate that test also with the other router.
Co-authored-by: Éric <merwok@netwok.org>
Co-authored-by: Éric <merwok@netwok.org>
I have added a small change to address the semantic issue pointed by @camuthig. |
that's great. do you see any other documentation changes needed for this? |
|
||
class MyModelViewSet(mixins.RetrieveModelMixin, viewsets.GenericViewSet): | ||
lookup_field = 'my_model_id' | ||
lookup_value_regex = '[0-9a-f]{32}' | ||
|
||
class MyPathModelViewSet(mixins.RetrieveModelMixin, viewsets.GenericViewSet): | ||
lookup_field = 'my_model_uuid' | ||
lookup_value_converter = 'uuid' |
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.
can we use better name for lookup_value_converter?any better suited name instead of converter?
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 used "converter" since django calls these elements path converters, maybe we can use the full expanded name to have lookup_value_pathconverter
(or lookup_value_path_converter
).
Any suggestion is welcome.
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 would inclined to @tomchristie for a better insight here as I'm bit confused about naming
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.
what about just lookup_value_path? this alighned with the name lookup_value_regex
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 that it would be better to use the same naming of django.
In this case it was named "converter" thus an attribute which should define one should be named after that. In this way it is easier to find references to what this element does.
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.
OK I am going to merge this, we can improve it if needed
Description
Add
SimplePathRouter
to handle Django 2.x path converters (refs #6148).