Django 2.1 Models Importing Custom User Model
I have been working on an extended User model in my Django 2.1 project. I am curious to know if the way in which I am importing my CustomUser model into another model (for use as a ForeinKey) is the correct way of doing so.
I have encountered verbiage in the past indicating that it is not correct to simple import the User model from the admin app, but rather import it from django.conf.
example importing from the base User model:
from django.conf import settings
User = settings.AUTH_USER_MODEL
...
class <ModelName>(models.mode):
user = ForeignKey(User, on_delete=models.CASCADE, default=1)
Now that I am using a CustomUser Model (extending AbstractUser),
users/models.py:
class CustomUser(AbstractUser):
objects = CustomUserManager()
def __str__(self):
return self.username
Is it better practice to import this model via setting (as shown above) or is how I am doing it below (in my Post app) the right way to it:
posts/models.py:
from users.models import CustomUser
class Post(models.Model):
user = models.ForeignKey(CustomUser, on_delete=models.CASCADE, default=1)
I am assuming this is the wrong way to go about this, but I am not sure why, can someone let me know why the above is not best practice? Note: It does get the job done though.
Thanks!
django django-models django-admin
asked Nov 17 '18 at 23:19
Andy GAndy G
168113
add a comment |
I have been working on an extended User model in my Django 2.1 project. I am curious to know if the way in which I am importing my CustomUser model into another model (for use as a ForeinKey) is the correct way of doing so.
I have encountered verbiage in the past indicating that it is not correct to simple import the User model from the admin app, but rather import it from django.conf.
example importing from the base User model:
from django.conf import settings
User = settings.AUTH_USER_MODEL
...
class <ModelName>(models.mode):
user = ForeignKey(User, on_delete=models.CASCADE, default=1)
Now that I am using a CustomUser Model (extending AbstractUser),
users/models.py:
class CustomUser(AbstractUser):
objects = CustomUserManager()
def __str__(self):
return self.username
Is it better practice to import this model via setting (as shown above) or is how I am doing it below (in my Post app) the right way to it:
posts/models.py:
from users.models import CustomUser
class Post(models.Model):
user = models.ForeignKey(CustomUser, on_delete=models.CASCADE, default=1)
I am assuming this is the wrong way to go about this, but I am not sure why, can someone let me know why the above is not best practice? Note: It does get the job done though.
Thanks!
django django-models django-admin
asked Nov 17 '18 at 23:19
Andy GAndy G
168113
add a comment |
I have been working on an extended User model in my Django 2.1 project. I am curious to know if the way in which I am importing my CustomUser model into another model (for use as a ForeinKey) is the correct way of doing so.
I have encountered verbiage in the past indicating that it is not correct to simple import the User model from the admin app, but rather import it from django.conf.
example importing from the base User model:
from django.conf import settings
User = settings.AUTH_USER_MODEL
...
class <ModelName>(models.mode):
user = ForeignKey(User, on_delete=models.CASCADE, default=1)
Now that I am using a CustomUser Model (extending AbstractUser),
users/models.py:
class CustomUser(AbstractUser):
objects = CustomUserManager()
def __str__(self):
return self.username
Is it better practice to import this model via setting (as shown above) or is how I am doing it below (in my Post app) the right way to it:
posts/models.py:
from users.models import CustomUser
class Post(models.Model):
user = models.ForeignKey(CustomUser, on_delete=models.CASCADE, default=1)
I am assuming this is the wrong way to go about this, but I am not sure why, can someone let me know why the above is not best practice? Note: It does get the job done though.
Thanks!
django django-models django-admin
asked Nov 17 '18 at 23:19
Andy GAndy G
168113
I have been working on an extended User model in my Django 2.1 project. I am curious to know if the way in which I am importing my CustomUser model into another model (for use as a ForeinKey) is the correct way of doing so.
I have encountered verbiage in the past indicating that it is not correct to simple import the User model from the admin app, but rather import it from django.conf.
example importing from the base User model:
from django.conf import settings
User = settings.AUTH_USER_MODEL
...
class <ModelName>(models.mode):
user = ForeignKey(User, on_delete=models.CASCADE, default=1)
Now that I am using a CustomUser Model (extending AbstractUser),
users/models.py:
class CustomUser(AbstractUser):
objects = CustomUserManager()
def __str__(self):
return self.username
Is it better practice to import this model via setting (as shown above) or is how I am doing it below (in my Post app) the right way to it:
posts/models.py:
from users.models import CustomUser
class Post(models.Model):
user = models.ForeignKey(CustomUser, on_delete=models.CASCADE, default=1)
I am assuming this is the wrong way to go about this, but I am not sure why, can someone let me know why the above is not best practice? Note: It does get the job done though.
Thanks!
django django-models django-admin
django django-models django-admin
asked Nov 17 '18 at 23:19
Andy GAndy G
168113
asked Nov 17 '18 at 23:19
Andy GAndy G
168113
asked Nov 17 '18 at 23:19
Andy GAndy G
168113
asked Nov 17 '18 at 23:19
Andy GAndy G
168113
asked Nov 17 '18 at 23:19
Andy GAndy G
168113
168113
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
There's nothing wrong with the way you are importing. The "settings" way of importing is merely a round-about way to get to the underlying model, since Django allows you to use a custom Model for user authentication handling.
Even better, however, is using the "lazy" load approach, which doesn't require any import statements at all:
user = models.ForeignKey('CustomUser', on_delete=models.CASCADE, default=1)
Be careful using a default on a ForeignKeyField, by the way. You need to be absolutely certain that the default value you provide will already be present, and will never disappear from the database.
answered Nov 18 '18 at 1:37
Jonah BishopJonah Bishop
8,86233257
Thanks Jonah - I don't really have a need for a default user in this case anyway. I will remove it and set blank=True to avoid any potential problems.
– Andy G
Nov 19 '18 at 0:04
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53356489%2fdjango-2-1-models-importing-custom-user-model%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
There's nothing wrong with the way you are importing. The "settings" way of importing is merely a round-about way to get to the underlying model, since Django allows you to use a custom Model for user authentication handling.
Even better, however, is using the "lazy" load approach, which doesn't require any import statements at all:
user = models.ForeignKey('CustomUser', on_delete=models.CASCADE, default=1)
Be careful using a default on a ForeignKeyField, by the way. You need to be absolutely certain that the default value you provide will already be present, and will never disappear from the database.
answered Nov 18 '18 at 1:37
Jonah BishopJonah Bishop
8,86233257
Thanks Jonah - I don't really have a need for a default user in this case anyway. I will remove it and set blank=True to avoid any potential problems.
– Andy G
Nov 19 '18 at 0:04
add a comment |
There's nothing wrong with the way you are importing. The "settings" way of importing is merely a round-about way to get to the underlying model, since Django allows you to use a custom Model for user authentication handling.
Even better, however, is using the "lazy" load approach, which doesn't require any import statements at all:
user = models.ForeignKey('CustomUser', on_delete=models.CASCADE, default=1)
Be careful using a default on a ForeignKeyField, by the way. You need to be absolutely certain that the default value you provide will already be present, and will never disappear from the database.
answered Nov 18 '18 at 1:37
Jonah BishopJonah Bishop
8,86233257
Thanks Jonah - I don't really have a need for a default user in this case anyway. I will remove it and set blank=True to avoid any potential problems.
– Andy G
Nov 19 '18 at 0:04
add a comment |
There's nothing wrong with the way you are importing. The "settings" way of importing is merely a round-about way to get to the underlying model, since Django allows you to use a custom Model for user authentication handling.
Even better, however, is using the "lazy" load approach, which doesn't require any import statements at all:
user = models.ForeignKey('CustomUser', on_delete=models.CASCADE, default=1)
Be careful using a default on a ForeignKeyField, by the way. You need to be absolutely certain that the default value you provide will already be present, and will never disappear from the database.
answered Nov 18 '18 at 1:37
Jonah BishopJonah Bishop
8,86233257
There's nothing wrong with the way you are importing. The "settings" way of importing is merely a round-about way to get to the underlying model, since Django allows you to use a custom Model for user authentication handling.
Even better, however, is using the "lazy" load approach, which doesn't require any import statements at all:
user = models.ForeignKey('CustomUser', on_delete=models.CASCADE, default=1)
Be careful using a default on a ForeignKeyField, by the way. You need to be absolutely certain that the default value you provide will already be present, and will never disappear from the database.
answered Nov 18 '18 at 1:37
Jonah BishopJonah Bishop
8,86233257
answered Nov 18 '18 at 1:37
Jonah BishopJonah Bishop
8,86233257
answered Nov 18 '18 at 1:37
Jonah BishopJonah Bishop
8,86233257
answered Nov 18 '18 at 1:37
Jonah BishopJonah Bishop
8,86233257
8,86233257
Thanks Jonah - I don't really have a need for a default user in this case anyway. I will remove it and set blank=True to avoid any potential problems.
– Andy G
Nov 19 '18 at 0:04
add a comment |
Thanks Jonah - I don't really have a need for a default user in this case anyway. I will remove it and set blank=True to avoid any potential problems.
– Andy G
Nov 19 '18 at 0:04
Thanks Jonah - I don't really have a need for a default user in this case anyway. I will remove it and set blank=True to avoid any potential problems.
– Andy G
Nov 19 '18 at 0:04
Thanks Jonah - I don't really have a need for a default user in this case anyway. I will remove it and set blank=True to avoid any potential problems.
– Andy G
Nov 19 '18 at 0:04
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53356489%2fdjango-2-1-models-importing-custom-user-model%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
