Re: Different auth user models withoout doing multi-table inheritance

> > > Hi James, thanks for the elaborate answer. Not that explicit OneToOne > relationships are bad but I was just trying to avoid the overhead due to > the JOINs that comes with it. > >> >> Understood. Unless you specifically request the data either by accessing the .merchant_data FK attribute or

Re: Different auth user models withoout doing multi-table inheritance

On Tuesday, August 11, 2015 at 2:31:11 AM UTC+5:30, James Schneider wrote: > > On Mon, Aug 10, 2015 at 12:11 PM, Ankit Agrawal > wrote: > >> Hi James, >> >> Correct me if I am wrong but if I understood you correctly, I should >> be able to implement it this way - >>

Re: Different auth user models withoout doing multi-table inheritance

On Mon, Aug 10, 2015 at 12:11 PM, Ankit Agrawal wrote: > Hi James, > > Correct me if I am wrong but if I understood you correctly, I should > be able to implement it this way - > > class User(AbstractBaseUser, PermissionsMixin): > common_fields_go_her = ... > >

Re: Different auth user models withoout doing multi-table inheritance

Hi James, Correct me if I am wrong but if I understood you correctly, I should be able to implement it this way - class User(AbstractBaseUser, PermissionsMixin): common_fields_go_her = ... objects = CustomUserManager() class Meta: abstract = True class

Re: Different auth user models withoout doing multi-table inheritance

That is an incorrect assumption. Abstract model classes do not generate any database tables, and are specifically designed for inheritance purposes (otherwise they are pretty much useless). It is impossible for a OneToOne field to exist that points to an abstract class.

Re: Different auth user models withoout doing multi-table inheritance

@James: Even if I implement a Custom abstract class inheriting from AbstractBaseUser, the Custom Abstract Class would have a explicit OneToOneField to the AbstractBaseUser, which essentially would mean having overheads due to JOINs as in MTI. Ankit Agrawal, IIT Bombay. On Mon, Aug 10, 2015 at

Re: Different auth user models withoout doing multi-table inheritance

If you want to avoid MT inheritance, look at inheriting from AbstractBaseUser using a custom abstract class where you can add your extra custom fields. Your two types of users (inheriting from your new abstract class) would then be standard, separate models. -James On Aug 10, 2015 9:24 AM, "Robin

Re: Different auth user models withoout doing multi-table inheritance

Hello Ankit, On 08/10/2015 09:38 AM, Ankit Agrawal wrote: > I am working on a project which has two different sets of users - > |Customer| and |Merchant|. Both of these users should be able to > register and login to their respective profiles. The most obvious choice > to implement this that came

Re: Different auth user models withoout doing multi-table inheritance

You surely can use Choice field for either Customer or Merchant in your custom user class. On 10 Aug 2015 20:12, "Avraham Serour" wrote: > I personally like a profile model, but if you implement two you may have > headaches when doing a reverse relation from user, you would

Re: Different auth user models withoout doing multi-table inheritance

I personally like a profile model, but if you implement two you may have headaches when doing a reverse relation from user, you would need to check every time of the request.user is a customer or merchant. In any case what is the difference between them anyway? Why can't a user be both? On Mon,

Different auth user models withoout doing multi-table inheritance

I am working on a project which has two different sets of users - Customer and Merchant. Both of these users should be able to register and login to their respective profiles. The most obvious choice to implement this that came to my mind was to make two different models Customer and