Hi Stephan, > I had this because it wasn't clear to me if perform_create replaced pre_save > or post_save in DRF 2.x.
It’s not a pure replacement but rather a placeholder for pre_save / save / post_save at the same time. > For the case I illustrate above, we should be able to quickly see how I ended > up with plaintext passwords in my database: > Even though the serializer class was creating hte User object and calling > that instance's set_password() method, when the serializer's create() method > returned to perform_create, the serializer.save() method was clobbering the > instance data with effectively stale data from data the serializer instance > had before the serializer class's create() method was called. So password was > being set back to what the serializer class would have had for > validated_data['password’]. It’s not clear to me why you password was stored in clear. However, two things strike me: - Why not popping password out of the validated_data since you don’t want it to be stored in clear ? - Why not using Django’s build in user’s manager create_user instead of raw create ? Both point are out of the scope of DRF and pure Django user things. > So the docs are write, this does replace pre_save and post_save, just not in > a very clear way. In fact, it's more like post_save using pre_save data. Argh. Could you be more specific here ? It seems pretty clear to me. > My own recco for the docs is to be clear that this perform_create really > replaces post_save(), and one should be careful using serializer.save() > within perform_create() because it might save data back to your model > instance that had not been intended to be saved without some prior > transformation. As stated above, my feeling is that it’s a development issue unrelated to DRF. There was a misunderstanding about how User’s password is stored by Django which is independent from DRF. > Alternatively, perhaps the docs should recco that the serializer really just > be there as a convenience for ingesting input data and validation, and that > actual db model instnace create() calls should be placed only in the > perform_create() method and that the serializer class create() method should > not hold such calls. Same as the previous comment. -- You received this message because you are subscribed to the Google Groups "Django REST framework" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
