Accessing serializer.data in a validate method shouldn't return stale data

[pzrq]

Example test case I think illustrates the issue:
https://github.com/mathspace/django-rest-framework/compare/validation-race

If I call self.data inside a serializer.validate, the existing stale instance data ends up cached on serializer._data. The workaround that passed my tests was to access serializer.instance instead.

Curious as to thoughts on this, e.g.

• Should serializer.data be accessible inside the validate methods, i.e. while the serializer is essentially still under construction?
• Or should the _data cache be appropriately flushed so the test can pass?

I would lean towards the former only because the serializer.data by being partly constructed could be quite misleading.

[lovelydinosaur]

If I call self.data inside a serializer.validate

You certainly shouldn't be doing that, no. Not clear what the intention would be.
Don't know if we can protect against it easily tho.

[pzrq]

Thanks for the quick reply. If you think of a reasonable way to protect
against it then great, if not feel free to close this as I reckon Google
will turn it up in case someone else runs into it.

On Monday, December 15, 2014, Tom Christie notifications@github.com wrote:

If I call self.data inside a serializer.validate

You certainly shouldn't be doing that, no. Not clear what the intention
would be.
Don't know if we can protect against it easily tho.

—
Reply to this email directly or view it on GitHub
#2276 (comment)
.

Cheers,

Peter Schmidt
peter@peterjs.com / peterjs38@gmail.com
+61 404 630 400

[lovelydinosaur]

Let's close it off for now - there might be further improvements we could make to restricting how the serializers can validly be called, but I can't see anything obvious at the moment.

[lovelydinosaur]

Opened #2289 to improve the constraints around this - eg raise a helpful error when this is attempted.