Hi Chris,
Why pick one over the other? Two potential reasons spring to mind:
1) Foreign keys aren't free, so if you're going to be using the extra
data field a lot, you can save yourself some database load (and some
syntactic cleanliness).
BUT
2) If you get in the habit of just putting everything on your custom
User model, you may find that your User models become very heavyweight
and not especially portable between projects. The portability of the
User model itself may not matter, but it will affect any model that
uses your User model - the more you attach to User, and the more code
that depends on those attachments, the harder it will be to reuse code
that depends on those attachments.
There's a balance between the two to be struck, which will ultimately
be driven by your own usage patterns more than any generic advice.
Yours,
Russ Magee %-)
On Fri, Oct 5, 2012 at 2:44 AM, Chris Pagnutti <chris.pagnu...@gmail.com> wrote:
> Hi. Thanks to everyone again for your replies. I've just been wondering,
> are there any reasons not to subclass the User class to add extra fields to
> a custom "User", versus the Foreign key method?
>
>
> On Thursday, September 27, 2012 4:13:34 PM UTC-4, Tundebabzy wrote:
>>
>> No you won't be smitten.
>>
>> As for isolating your edited django, you can do that but then you
>> would have to be responsible for improving the code base by yourself.
>> Also, your edit might inadvertently break django or introduce bugs
>> that you might find difficult to trace and solve or that might change
>> some of the logic required to make django work.
>>
>> On 9/27/12, Chris Pagnutti <chris.p...@gmail.com> wrote:
>> > Hi. First-time poster here. Feel free to point out any rules I'm not
>> > following.
>> >
>> > I've been looking around for how to make the django.contrib.auth User
>> > classe's "email" field to be unique and required. There are bunches of
>> > ways to do it, but it's just soooo darn easy to go into the source and
>> > change how the field is defined.
>> > e.g. email = models.EmailField(_('email address'),unique=True)
>> >
>> > But in my searches, I've read warnings that you should not do this. The
>> > reason, if it is given, is that you'll break your app if you update the
>> > contrib packages. But what if I work in virtualenvs and just leave the
>> > django version and packages intact for that particular app in that
>> > particular environment? What are the other practical and philosophical
>> > reasons for NOT editing the contrib source? Will I be smitten from the
>> > django community if I do so?
>> >
>> > Thanks to all.
>> >
>> > --
>> > You received this message because you are subscribed to the Google
>> > Groups
>> > "Django users" group.
>> > To view this discussion on the web visit
>> > https://groups.google.com/d/msg/django-users/-/YX9X8u9mdbwJ.
>> > To post to this group, send email to django...@googlegroups.com.
>> > To unsubscribe from this group, send email to
>> > django-users...@googlegroups.com.
>> > For more options, visit this group at
>> > http://groups.google.com/group/django-users?hl=en.
>> >
>> >
>>
>> --
>> Sent from my mobile device
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/django-users/-/KYZyzsq4H4IJ.
>
> To post to this group, send email to django-users@googlegroups.com.
> To unsubscribe from this group, send email to
> django-users+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-users?hl=en.
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
