1

I'm writing an application where I need to register user information even if the user does not exists (yet) in Django. Basically I need to insert almost every fields used by Auth.user (I don't care about password). I've also created a Profile model connected with a OneToOneField to the Auth.user model and I need to fill in these fileds as well for users that do not exist yet.

If a user will register later to the site (using Auth.user) I will look for him by email and if I will find him I will merge my inserted information and the ones that he provided.

QUESTION: What is the best approach to implement user persistence without repeating myself in creating models very similar to each other?

Leonardo
  • 4,046
  • 5
  • 44
  • 85
  • 1
    I would keep it very simple, and use the `is_active` flag and the emptiness of the password field (together) to figure out if the user created the account or not. At the time of registration, if the profile exists, just prompt him to validate the email, and set a password - You should be all set – karthikr Aug 17 '13 at 18:32
  • I have a seller-customer system where different sellers can access different customers. If _Seller1_ registers _customer1_ and set `is_active` as `false`, then if _Seller2_ would like to insert his own info about _customer1_ there would be conflict. Also, what if the _customer1_ deletes his account? For privacy concerns the system should delete all the information he provided (but not the ones that the sellers provided about the customers) – Leonardo Aug 19 '13 at 19:02
  • Ok. Handle the information by creating a level of abstraction (UserProfile) and extend it to cater to your needs – karthikr Aug 19 '13 at 19:43

1 Answers1

0

I would recommend using a dummy value in either the date_joined or last_login fields for the User model, if you wanted to implement a solution without adding a new field just to serve as an indicator flag.

The potential problem with using the is_active flag is that you may end up wanting to use this flag to "blacklist" or effectively delete an account without actually removing their record from your database (to prevent re-creation of the account with same credentials, etc.) If you start relying on the fact that the password is not set, then if the day ever comes where you want to implement alternative login methods (OAuth) then your password field will not be set in these cases as well (huge conflict).

Joseph Paetz
  • 876
  • 1
  • 7
  • 12