A revamp... I have to migrate again 😆

There are two methods for me. The easy method is to store everything under one table, and make the dynamic fields nullable; the hard method is to separate them into separate models, and, thereby, tables.

Issues that I have with the easy method:

• They use different OAuth providers exclusive of each other
• I have to filter every time I want to get from either group
• The tables cannot be handled exclusive of each other, GDPR (?)

Exclusive scenario for hard method that could be useful for some

Refer to the two models as A or B: Sam is a user with model A, however, as he no longer is no longer a part of the restricted OAuth2.0 and he becomes a User B, which is a more general OAuth2.0. The user in A is deactivated. We create a OneToOne field from B to A to store the history of the user, no deletions, two IDs; one for the past and one for the present.

Design idea

user_db_model could store the models in a tuple, and have them checked in parallell when we query our user. Not sure how this would work downstream from there.

A revamp... I have to migrate again 😆

Sorry, it's for the good of all 😅

Well, I'm not sure I clearly understand all the implications in your case but, generally-speaking, I strongly recommend to keep users in a single table. It'll likely cause you lot of problems in the long run.

If you have two types of users that are not sharing the same attributes, a good approach is to define those attributes in separate tables and make a foreign key on the User table. Something like this:

classDiagram
    class User{
        id
        email
        hashed_password
        is_active
        is_verified
        is_superuser
    }
    class UserTypeA {
        id
        user_id
        attribute_a1
        attribute_a2
    }
    class UserTypeB {
        id
        user_id
        attribute_b1
        attribute_b2
    }
    UserTypeA "1" --> "1" User
    UserTypeB "1" --> "1" User

• This way, the basic authentication data is stored centrally in the User table.
• If the user is of type A, it'll have a row in the UserTypeA table.
• If the user is of type B, it'll have a row in the UserTypeB table.

In SQLAlchemy, you can even set the reverse relationship, so you can access it from the User object.

Now, when a user transitions from type A to B, all you have to do is to delete the corresponding row from UserTypeA and insert a new one in UserTypeB. The User table is untouched.

Tell me if that makes sense for you!

OK, I'll go with that.

Reverse relationship in tortoise ORM?

Hey @frankie567, I am having similar issues except I have 5 different types of users. One thing doesn't get in my head is how will fastapi-users know which one is getting registered. For logging I have a base one that is easy. But for registering do I need different auth backends, user managers for each role or how is that done ?

Sorry if this has been already answered somewhere. Can't really find an example.