2011-05-18 6 views
14

J'ai eu une clé primaire personnalisée qui doit être configurée sur une donnée particulière dans un modèle.Clé primaire et clé unique dans django

Cela ne suffisait pas, car une tentative d'insertion d'un numéro en double a réussi. Alors maintenant quand je remplace primary_key=True à unique=True il fonctionne correctement et rejette les numéros en double !! Mais selon ce document (qui utilise les champs).

primary_key=True implique null=False et unique=True.

Ce qui me fait confus comme pourquoi il accepte la valeur en premier lieu d'avoir un unique=True intégré?

Merci.

déclaration Mise à jour:

personName = models.CharField(primary_key=True,max_length=20) 

Répondre

13

Utilisez un AutoField avec primary_key à la place.

Edit:

Si vous ne l'utilisez pas AutoField, vous devrez calculer manuellement/définir la valeur pour le champ de clé primaire. C'est plutôt lourd. Y at-il une raison pour laquelle besoinReportNumber à la clé primaire? Vous pouvez toujours avoir un numéro de rapport unique sur lequel vous pouvez effectuer une requête pour les rapports, ainsi qu'une clé primaire d'entier auto-incrémentée.

Edit 2:

Quand vous dites en double clé primaire sont autorisées, vous indiquez que ce qui se passe est qu'un enregistrement existant avec la même clé primaire est mise à jour - il n'y a pas en fait deux objets la même clé primaire dans la base de données (ce qui ne peut pas arriver). Le problème réside dans la façon dont la couche ORM de Django choisit de faire UPDATE (modifier un enregistrement de base de données existant) par rapport à INSERT INTO (créer un nouvel enregistrement de base de données). Découvrez cette ligne de django.db.models.base.Model.save_base():

if (force_update or (not force_insert and 
     manager.using(using).filter(pk=pk_val).exists())): 
    # It does already exist, so do an UPDATE. 

En particulier, ce bout de code:

manager.using(using).filter(pk=pk_val).exists() 

Cela dit: « Si un enregistrement avec la même clé primaire que ce Model existe dans la base de données, puis faire une mise à jour." Donc, si vous réutilisez une clé primaire, Django suppose que vous faites une mise à jour, et donc ne déclenche pas d'exception ou d'erreur.


Je pense que la meilleure idée est de laisser Django générer une clé primaire pour vous, puis un champ distinct (CharField ou autre) qui a la contrainte unique.

+0

@Nagaraj Tantri: J'ai édité ma réponse pour répondre à votre commentaire. – mipadi

+1

@mipadi: Mes exigences sont en ce qui concerne le fait de le définir manuellement. Je comprends votre préoccupation pour 'AutoFiled'. Mais encore une fois, votre solution permettrait de résoudre la requête où je veux que ce soit AutoField.La chose que je voulais est une entrée manuelle du bureau d'enregistrement pour cela. Encore une fois, même si j'utilise ** CharFiled **, je remplacerais le champ original par le nouvel enregistrement 'CharField'. Et si vous notez la dernière partie de ma question, j'ai demandé un doute quant à pourquoi cela ne fonctionne pas? Pourquoi il remplace même quand il a par défaut 'unique = True' dans' primary_key'? –

+1

@Nagaraj Tantri: Droit. Je demande pourquoi le numéro de rapport doit être la clé primaire. Vous pouvez avoir un numéro de rapport unique et saisi manuellement (vous pouvez même l'indexer pour effectuer des requêtes plus rapidement), ainsi qu'un numéro d'identification distinct généré automatiquement (qui est également la clé primaire). – mipadi