Django pre_save signal - would an exception fail the transaction?

Question

I want to do some custom actions before a user is created. and I thought of using the pre_save signal for that. And in case one of those action would raise an exception stop the transaction, abort creating the user etc.

1. Is this the way to go? would it abort the save if something fails in this step (this is the required behavior) I suspect so but couldn't find docs about it.

2. What is the best practice for getting the future user.id. from my understanding it doesn't exists yet in pre-save but I need it as input for some of the extra custom actions.

Thanks

Answer 1

From the docs:

There's no way to tell what the value of an ID will be before you call save(), because the value is determined by your database, not by Django.

So if your pre-save processing requires the user.id, I am afraid this is not possible.

Answer 2

Here is the two part answer:

1. Yes, raising an exception in the pre_save() signal will abort the call to the save() method. For example, I did this in my pre_save():

   if SOME_TEST:
       raise exceptions.ParseError(detail="I reject your data. Here is why.")
   

   Note: This was using the DRF exceptions, but I will assume you know how to raise whatever exception you prefer.

2. You could use the post_save() signal to get the id AFTER the save() method. But if that will not work for you, then below is my original explanation of some tactics to do what you want in the pre_save():

In the pre_save you can access User.objects.all() (if you import the User model, of course). If you are using the standard User model then the User.id value is AUTO INCREMENT. So if you NEED to know what the value WILL be for the new user, just get the highest User.id currently in the database (ie: the id of the last user created). Here is a simple query to do this:

last_user = User.objects.latest('id')

Then of course, last_user.id will give you the value of the id for the last user created and if you add one to that you will have the next user id. Of course, if you have a busy site you may have some problems with simultaneous user creation. The risk is that this value is received by two (or more) User creation attempts and one (or more) of them ends up wrong.

Of course, you can always set another field to be primary_key=True and this will replace the id field on the model. Then you can devise any sort of indexing mechanism that you can dream up! You could use a hash value of a unique characteristic. For example: The User.username has a Unique constraint, you could hash or hex encode that as a numeric ID to pre-determine the User.id. Or you could leave the id field in place and set it manually in the pre_save by assigning a value to obj.id. It could be anything you want. Even a hash value!