Comments (11)
I guess my concern is largely with the fact that it didn't follow the deprecation policy, but also with the change itself.
Our code base is pretty extensively tested, but we generally do not go out of our way to test the core functionality in the libraries we use. The fact that there was this breaking change when there was, according to the policy, not supposed to be any, now has me concerned about other changes that might break something in our API that are not as obvious.
Perhaps having more, smaller, releases could help mitigate some of these issues too. As you say, bundling over a year's worth of updates at once makes for a lot of potential places for issues to arise.
When it comes to the specific change, there are many cases where it doesn't necessarily even make sense to specify the queryset, the most obvious one being when the result of get_object
is the user on the request, but of course there are many others. There may be cases where get_object
is not even returning a django model object, but maybe a dict or some other type. Forcing the queryset to be defined in some of these cases just seems unintuitive.
I am obviously not as familiar with the overall code in the library, so I won't argue what should or should not be done, but it seems like some of the use cases were potentially overlooked, and while defining the queryset might be the optimal solution, making it required in these cases seems perhaps unncessary.
from django-rest-framework.
While I agree that it didn't really follow the advertised deprecation policy, in the case of the 3.15 release, it was a long time coming, and having 1.5 years separating it with the previous release was bound to contain unintended breaking changes...
That's a really concerning statement. Mature software with few releases generally is extraordinarily stable, not extraordinarily unstable.
So... I'm in complete agreement here.
We've got two different aspects to be addressed here...
- Releasing a 3.15.1 version, with appropriate fixes in place.
- Ensuring that we make the project PR policy really clear, and ensure that REST framework isn't accepting further changes other than security related fixes and changes required by newer Django versions.
from django-rest-framework.
So if I read that correctly, the error message is not really an issue anymore,
For those who happen to have "fixed" their downstream code. It is still a DRF regression.
but your concern is more around the fact that it was a breaking change despite the major digit of DRF not having changed? Would adding this to the release note be enough to close this issue?
Not at all! A patch release with a fix in DRF is required, or alternatively the release should be withdrawn and re-released with a major version bump.
While I agree that it didn't really follow the advertised deprecation policy, in the case of the 3.15 release, it was a long time coming, and having 1.5 years separating it with the previous release was bound to contain unintended breaking changes...
That's a really concerning statement. Mature software with few releases generally is extraordinarily stable, not extraordinarily unstable.
There's another regression caught by our application-side tests. I haven't had time to report it, but am planning to do so later this week.
In my view, this is a symptom of a larger issue, as it suggests that DRF has insufficient test coverage.
The fix I suggest would work in simple case, but would still require you to override the queryset in case of prefetches, and it's probably OK. In more complex cases, the error message tells exactly what is wrong, and user can easily fix it.
The code should simply gracefully handle (the exception in) scenarios where the queryset isn't defined or not of the expected type.
from django-rest-framework.
While I agree that it didn't really follow the advertised deprecation policy, in the case of the 3.15 release, it was a long time coming, and having 1.5 years separating it with the previous release was bound to contain unintended breaking changes...
That's a really concerning statement. Mature software with few releases generally is extraordinarily stable, not extraordinarily unstable.
So... I'm in complete agreement here.
We've got two different aspects to be addressed here...
- Releasing a 3.15.1 version, with appropriate fixes in place.
- Ensuring that we make the project PR policy really clear, and ensure that REST framework isn't accepting further changes other than security related fixes and changes required by newer Django versions.
This is good to hear.
My biggest concern was not that I had to update my code with a new release, its that this was a point release that should not have required me to do so.
I am most concerned about what other updates were made that may cause issues that are not as immediately obvious, and it seems like there are at least a few others looking at the issue list.
The whole situation has left me less confident in future DRF releases and considering rolling back to 3.14 as I know that it is stable and have much higher confidence in it behaving as I expect.
from django-rest-framework.
In the end, I already updated all of the relevant code to define the queryset on my views, but the nature of the breaking change is concerning for others using the library.
So if I read that correctly, the error message is not really an issue anymore, but your concern is more around the fact that it was a breaking change despite the major digit of DRF not having changed? Would adding this to the release note be enough to close this issue?
While I agree that it didn't really follow the advertised deprecation policy, in the case of the 3.15 release, it was a long time coming, and having 1.5 years separating it with the previous release was bound to contain unintended breaking changes...
The fix I suggest would work in simple case, but would still require you to override the queryset in case of prefetches, and it's probably OK. In more complex cases, the error message tells exactly what is wrong, and user can easily fix it.
from django-rest-framework.
While I agree that it didn't really follow the advertised deprecation policy, in the case of the 3.15 release, it was a long time coming, and having 1.5 years separating it with the previous release was bound to contain unintended breaking changes...
How can there be unintended breaking changes in a point release? This is extremely concerning.
from django-rest-framework.
So if I read that correctly, the error message is not really an issue anymore,
For those who happen to have "fixed" their downstream code. It is still a DRF regression.
but your concern is more around the fact that it was a breaking change despite the major digit of DRF not having changed? Would adding this to the release note be enough to close this issue?
Not at all! A patch release with a fix in DRF is required, or alternatively the release should be withdrawn and re-released with a major version bump.
Definitely agreed here - this is a regression and should be addressed.
from django-rest-framework.
We just ran into this too. Also interested to know if it was intentional - I feel like this has got to be a pretty common pattern?
Related PR: #8043
I worked around it for now by just adding ModelClass.objects.none()
to affected view classes, e.g.:
class MeView(generics.RetrieveUpdateAPIView):
+ queryset = User.objects.none()
serializer_class = MeSerializer
def get_object(self):
return self.request.user
from django-rest-framework.
Same here
from django-rest-framework.
What is your get_object()
method looking like? I started to look at a potential fix (#9314) but after opening the pull request I noticed that I made a pretty significant assumption, that the get_object
method isn't doing any prefetches.
from django-rest-framework.
What is your
get_object()
method looking like? I started to look at a potential fix (#9314) but after opening the pull request I noticed that I made a pretty significant assumption, that theget_object
method isn't doing any prefetches.
It is sometimes as simple as return request.user
or potentially doing a get_or_create
or a query on a queryset with many filters/select_related/prefetch_related/etc - there isn't one set pattern I have here.
I don't totally understand the rationale behind clearing and refetching the related objects, but perhaps it is something that is just documented as the best practice, but does not throw an error if the queryset property or get_queryset method is not defined?
In the end, I already updated all of the relevant code to define the queryset on my views, but the nature of the breaking change is concerning for others using the library.
from django-rest-framework.
Related Issues (20)
- 3.15 regression: ListSerializer ValidationErrors silently changed return type
- 3.15 regression: ListSerializer ValidationError nested structure silently changed HOT 1
- 3.15 regression: UpdateModelMixin breaks views using Manager objects as queryset HOT 4
- Version 3.15.1 HOT 1
- 3.15 regression: Unset default namespace version suddenly raises 404 HOT 3
- 3.15(.1?) regression: optional fields in serializers are suddenly required (or need explicit None passed) HOT 11
- UniqueConstraint violation_error_message as error response in drf
- rest-framework Supports async class views ?
- 3.15 regression: Serializer validation failed for unique together constraint HOT 2
- Revert changes to `CursorPagination` that caused serious performance regression HOT 3
- Router.register cannot merge with urlpatters HOT 3
- UniqueTogetherValidator does not comply to Database standards
- HyperlinkedModelSerializer doesn't respect SECURE_PROXY_SSL_HEADER settings
- 3.15 is raising required error on model nullable fields HOT 6
- DRF generic views not fire post_save signal HOT 11
- [self-tests] cleanup order of `TestUrlPatternTestCase` HOT 1
- a question about BooleanField HOT 3
- Issue with upgrade from 3.14 to 3.15.1, null values no longer allowed in POST HOT 3
- Incorrect serializer field in quickstart documentation HOT 2
- `coreapi` must be installed for schema support with Python 3.10 HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from django-rest-framework.