django modèles abstraits rapport régulier de l'héritage

En plus de la syntaxe, quelle est la différence entre l'utilisation d'un django modèle abstrait et à l'aide de la plaine Python héritage avec django modèles? Les avantages et les inconvénients?

Mise à JOUR: je pense que ma question a été mal compris et j'ai reçu les réponses de la différence entre un modèle abstrait et une classe qui hérite de django.db.modèles.De modèle. En fait je veux savoir la différence entre un modèle de classe qui hérite de django classe abstraite (Meta: abstract = True) et une plaine Python classe qui hérite de dire, "objet" (et pas des modèles.Modèle).

Voici un exemple:

class User(object):
   first_name = models.CharField(..

   def get_username(self):
       return self.username

class User(models.Model):
   first_name = models.CharField(...

   def get_username(self):
       return self.username

   class Meta:
       abstract = True

class Employee(User):
   title = models.CharField(...
InformationsquelleAutor rpq | 2013-05-20
  1. 115

    En fait je veux savoir la différence entre un modèle de classe
    hérite de django classe abstraite (Meta: abstract = True) et un
    plaine Python classe qui hérite de dire, "objet" (et non pas
    modèles.Modèle).

    Django ne fera que générer des tables pour les sous-classes de models.Model, de sorte que l'ancien...

    class User(models.Model):
   first_name = models.CharField(max_length=255)

   def get_username(self):
       return self.username

   class Meta:
       abstract = True

class Employee(User):
   title = models.CharField(max_length=255)

    ...va provoquer un tableau unique généré, le long des lignes de...

    CREATE TABLE myapp_employee
(
    id         INT          NOT NULL AUTO_INCREMENT,
    first_name VARCHAR(255) NOT NULL,
    title      VARCHAR(255) NOT NULL,
    PRIMARY KEY (id)
);

    ...alors que celui-ci...

    class User(object):
   first_name = models.CharField(max_length=255)

   def get_username(self):
       return self.username

class Employee(User):
   title = models.CharField(max_length=255)

    ...ne causera pas de tables à être généré.

    Vous pouvez utiliser l'héritage multiple pour faire quelque chose comme ça...

    class User(object):
   first_name = models.CharField(max_length=255)

   def get_username(self):
       return self.username

class Employee(User, models.Model):
   title = models.CharField(max_length=255)

    ...qui permettrait de créer un tableau, mais il ignore les champs définis dans la User classe, de sorte que vous finirez avec un tableau comme celui-ci...

    CREATE TABLE myapp_employee
(
    id         INT          NOT NULL AUTO_INCREMENT,
    title      VARCHAR(255) NOT NULL,
    PRIMARY KEY (id)
);
    • Merci, cela répond à ma question. C'est toujours pas clair pourquoi prenom est pas créé pour les Employés.
    • Vous devriez vérifier de Django reinhardt, le code source, mais SI elle utilise de la métaclasse hackery dans models.Model, de sorte que les champs définis dans la super-classe ne sera pas ramassé (sauf s'ils sont également des sous-classes de models.Model).
    InformationsquelleAutor Aya
  2. 31

    Un modèle abstrait crée un tableau avec l'ensemble des colonnes pour chaque subchild, tandis que l'utilisation de "plaine" Python héritage crée un ensemble de tables liées (aka "multi-héritage de table"). Considérons le cas où vous avez deux modèles:

    class Vehicle(models.Model):
  num_wheels = models.PositiveIntegerField()


class Car(Vehicle):
  make = models.CharField(…)
  year = models.PositiveIntegerField()

    Si Vehicle est un modèle abstrait, vous aurez un seul tableau:

    app_car:
| id | num_wheels | make | year

    Toutefois, si vous utilisez de la plaine Python héritage, vous aurez deux tables:

    app_vehicle:
| id | num_wheels

app_car:
| id | vehicle_id | make | model

    Où vehicle_id est un lien vers une ligne dans app_vehicle aussi le nombre de roues de la voiture.

    Maintenant, Django va mettre cela ensemble joliment en forme d'objet, de sorte que vous pouvez accéder à num_wheels comme un attribut sur Car, mais la représentation sous-jacente dans la base de données sera différent.

    Mise à jour

    À l'adresse de mise à jour de votre question, la différence entre l'héritage de Django classe abstraite et héritant de Python object est que le premier est considéré comme un objet de base de données (tables sont synchronisés avec la base de données) et il a le comportement d'un Model. Héritage d'une plaine Python object donne de la classe et de ses sous-classes) aucune de ces qualités.

    • Faire models.OneToOneField(Vehicle) revient à hériter d'une classe de modèle, non? Et qui aurait pour résultat de deux tableaux distincts, n'est-ce pas?
    • Oui, mais lors de l'utilisation de l'héritage, Django va faire, par exemple, num_wheels un attribut sur un car, alors qu'avec un OneToOneField vous aurez à faire référence à vous-même.
    • Comment puis-je la force régulière de l'héritage que tous les champs sont re-généré pour app_car table de sorte qu'il a aussi le num_wheels champ, au lieu d'avoir le vehicle_id pointeur?
    • Faire de la classe de base d'un modèle abstrait, et héritent de cette.
    • le problème est que je ne peut pas faire de la classe de base abstraite, il est utilisé à travers le projet.
    • Dans ce cas, les sous-classes auront un lien à la mère. Ceci est géré de manière transparente par Django, si.

    InformationsquelleAutor mipadi
  3. 8

    Voulais juste ajouter quelque chose dont je n'ai pas vu dans d'autres réponses.

    À la différence avec les classes python, nom du champ cacher est pas permis avec le modèle de l'héritage.

    Par exemple, j'ai expérimenté des problèmes avec un cas d'utilisation comme suit:

    J'ai eu un modèle héritant de django auth PermissionMixin:

    class PermissionsMixin(models.Model):
    """
    A mixin class that adds the fields and methods necessary to support
    Django's Group and Permission model using the ModelBackend.
    """
    is_superuser = models.BooleanField(_('superuser status'), default=False,
        help_text=_('Designates that this user has all permissions without '
                    'explicitly assigning them.'))
    groups = models.ManyToManyField(Group, verbose_name=_('groups'),
        blank=True, help_text=_('The groups this user belongs to. A user will '
                                'get all permissions granted to each of '
                                'his/her group.'))
    user_permissions = models.ManyToManyField(Permission,
        verbose_name=_('user permissions'), blank=True,
        help_text='Specific permissions for this user.')

    class Meta:
        abstract = True

    # ...

    Puis j'ai eu mon mixin qui, entre autres choses, j'ai voulu remplacer la related_name de la groups champ. Il était donc plus ou moins comme ceci:

    class WithManagedGroupMixin(object):
    groups = models.ManyToManyField(Group, verbose_name=_('groups'),
        related_name="%(app_label)s_%(class)s",
        blank=True, help_text=_('The groups this user belongs to. A user will '
                            'get all permissions granted to each of '
                            'his/her group.'))

    J'ai été en utilisant ce 2 mixin comme suit:

    class Member(PermissionMixin, WithManagedGroupMixin):
    pass

    Donc oui, je m'attendais à ce que le travail, mais il n'a pas.
    Mais le problème est plus grave que l'erreur que je recevais n'était pas pointant vers des modèles à tous, je n'avais aucune idée de ce qui allait mal.

    Tout en essayant de résoudre ce je au hasard décidé de changer ma mixin et la convertir en un modèle abstrait mixin. L'erreur a changé à cela:

    django.core.exceptions.FieldError: Local field 'groups' in class 'Member' clashes with field of similar name from base class 'PermissionMixin'

    Comme vous pouvez le voir, cette erreur ne peut expliquer ce qui se passe.

    C'était une énorme différence, à mon avis 🙂

    • J'ai une question qui n'est pas liée à la question principale ici, mais comment avez-vous réussi à mettre en œuvre des ce (pour remplacer le related_name des groupes de champ) à la fin ?
    • Autant que je me souvienne j'ai juste changé le nom de quelque chose d'autre entièrement. Il n'y a simplement aucun moyen de supprimer ou de remplacer hérité des champs.
    • Oui, j'étais prêt à renoncer à cela, quand j'ai trouvé un moyen de le faire à l'aide de la contribute_to_class méthode.
    InformationsquelleAutor Adrián
  4. 5

    La principale différence est la façon dont les tables de bases de données pour les modèles sont créés.
    Si vous utiliser l'héritage sans abstract = True Django va créer un tableau distinct pour les deux parents et le modèle de l'enfant qui détiennent les champs définis dans chaque modèle.

    Si vous utilisez abstract = True pour la classe de base de Django ne fera que créer une table pour les classes qui héritent de la classe de base, même si les champs sont définis dans la classe de base ou de la classe qui hérite.

    Avantages et les inconvénients dépend de l'architecture de votre application.
    Compte tenu de l'exemple suivant les modèles:

    class Publishable(models.Model):
    title = models.CharField(...)
    date = models.DateField(....)

    class Meta:
        # abstract = True

class BlogEntry(Publishable):
    text = models.TextField()


class Image(Publishable):
    image = models.ImageField(...)

    Si le Publishable classe n'est pas abstraite, Django va créer un tableau de publishables avec les colonnes title et date et des tables séparées pour les BlogEntry et Image. L'avantage de cette solution est que vous êtes en mesure de requête sur tous publishables pour les champs définis dans le modèle de base, peu importe si elles sont entrées de blog ou des images. Mais donc Django aurez à faire des jointures, par exemple si vous effectuez des recherches pour les images...
    Si Publishable abstract = True Django ne va pas créer une table pour Publishable, mais uniquement pour les entrées de blog et les images, contenant tous les champs (également celles héritées). Ce serait pratique car pas de jointures seraient nécessaires pour une opération telle que obtenir.

    Voir aussi De Django reinhardt, de la documentation sur le modèle de l'héritage.

    InformationsquelleAutor Bernhard Vallant
  5. 0

    La principale différence est que lorsque vous héritent de la classe Utilisateur. Une version se comporte comme une simple classe, et l'autre se comportent comme un Django modeel.

    Si vous héritez de la base "objet" version, votre Employé de classe sera une classe standard, et le prenom de ne pas faire partie d'une table de base de données. Vous ne pouvez pas créer un formulaire ou d'utiliser toute autre Django fonctionnalités avec elle.

    Si vous héritez les modèles.Version du modèle, votre classe d'Employés auront toutes les méthodes de Django Modèle, et il héritera de la prenom champ comme un champ de base de données qui peut être utilisé dans un formulaire.

    Selon la documentation, un Modèle Abstrait "fournit un moyen de factoriser les informations communes à l'Python niveau, tout en créant, d'une table de base de données par enfant modèle au niveau base de données."

    InformationsquelleAutor Brent Washburne