2013-06-02 23 views
5

Django 1.5+ pozwala nam dodawać pola niestandardowe do użytkownika. Chcę użyć tego faktu, ale niekoniecznie wiem, co to jest dobra praktyka. Oto sytuacja, w której jestem zdezorientowany, jak poradzić sobie z modelami.Django 1.5 + Relacja modelu użytkownika

możliwość, aby dodać pola do User, jeśli projekt ma jeden typ User tylko, powiedzmy do Student modelu, mogę po prostu dodać pola Student-specyficzne User? Jestem nowy w Django, ale uważam, że alternatywą byłoby ustawienie ogólnych ustawień User i utworzenie modelu Student i jedno-do-jednego unikalnego pola w tym wywołaniu użytkownika.

Czy kiedykolwiek chcesz rozwinąć pola Django User, aby naśladować to, co model, nawet jeśli projekt ma zagwarantowany tylko jeden typ użytkownika?

Odpowiedz

12

Jeśli masz tylko jednego typu użytkownika i używasz Django 1.5+, polecam skorzystanie z nowej funkcji AbstractUser. Extending Django's default user

Jako przykład, w którym chcesz dodać datę urodzenia i ulubiony kolor:

#myusers/models.py 
from django.contrib.auth.models import AbstractUser 
from django.db import models 

class MyUser(AbstractUser): 
    dob = models.DateField() 
    favorite_color = models.CharField(max_length=32, default='Blue') 

Jeśli potrzebujesz większej elastyczności można wydłużyć AbstractBaseUser zamiast AbstractUser, ale dla większości podstawowych przypadkach powinno wystarczy AbstractUser.

Należy również pamiętać, że w obu przypadkach trzeba będzie reference your user model by using settings.AUTH_USER_MODEL.

Korzystanie z przykładu powyżej zakładając aplikacji został zdefiniowany w nazywa myusers:

#settings.py 
AUTH_USER_MODEL = 'myusers.MyUser' 

Sposób wspomnieć o stworzenie modelu student z pola typu jeden-do-jednego do modelu użytkownika nadal działa , ale nie jest tak czysty (są jeszcze przypadki, w których ma to sens, jeśli masz wiele rodzajów użytkowników).

Zwykle nie lubią odwoływać się książki w odpowiedzi, ale uważam, że Two Scoops of Django's rozdział 16 na modelu użytkownika dał jaśniejszego wyjaśnienia gdzie różne opcje są odpowiednie niż obecnej wersji online Django docs. Książka jest ogólnie bardzo przydatnym wstępem do Django i została napisana w oparciu o 1.5. Musiałbyś kupić książkę lub znaleźć kogoś, kto ją ma ... (FYI: Nie dostaję za to żadnych pieniędzy).

Można też spojrzeć na to tak zapytania/odpowiedzi: https://stackoverflow.com/a/14104748/307293

+0

Co nie jest czyste? –

+3

Tworzy dodatkową tabelę w bazie danych. Jeśli często powołujesz się na takie rzeczy jak imię i nazwisko oraz niektóre niestandardowe informacje, które wymagają dodatkowego JOIN za każdym razem. – Jacinda

+0

Jacinda - przypadkowo kupiłem książkę już dziś! Jeszcze się tam nie dostałem, ale patrząc na to odwołanie, dają trzy dobre opcje: powiązanie z podobnym modelem, podklasą AbstractUser lub podklasą AbstractBaseClassUser. Niestety używam aplikacji innej firmy, którą chcę podklasować, wszelkich pomysłów, jak to zrobić? – Joker

0

Nie należy dotykać modelu Django wniesionego User (ze struktury uwierzytelniania). To przerwie aktualizacje i nie wiesz, jakie mogą mieć tego konsekwencje.

Istnieją dwa podstawowe sposoby, aby to zrobić:

  1. Jeśli wystarczy do przechowywania dodatkowych informacji o użytkowniku, ale nie trzeba zmieniać, jak działa mechanizm uwierzytelniania/autoryzacji, stworzenie modelu i dodaj model OneToOneField do modelu User. W tym modelu przechowuj wszelkie inne informacje.

  2. Jeśli chcesz zmienić sposób uwierzytelniania, możesz create your own User model i używać go przez django (tylko 1.5+).

+5

To nie jest poprawne, jeśli zaczynasz nową aplikację w 1,5. Nowe najlepsze praktyki, jeśli wystarczy dodać dodatkowe pola, to dziedziczyć po Abonentu. – Jacinda

+0

Nie, dziedziczysz tylko z AbstractUserModel podczas tworzenia modelu użytkownika _replacement_; i nie powinieneś tego robić, jeśli chcesz tylko dodać pole. Powinieneś stworzyć swój własny model zastępczy, jeśli wprowadzisz jakąś zasadniczą zmianę w sposobie, w jaki proces uwierzytelniania/autoryzacji będzie działał dla twojej aplikacji. –

+3

Nie mówię o AbstractBaseUser, który tworzy zamiennik. Mówię o AbstractUser. Z dokumentów: "Jeśli jesteś całkowicie zadowolony z modelu użytkownika Django i chcesz tylko dodać kilka dodatkowych informacji o profilu, możesz po prostu podklasować django.contrib.auth.models.AbstractUser i dodać własne pola profilu. pełna implementacja domyślnego użytkownika jako abstrakcyjnego modelu. " – Jacinda

Powiązane problemy