web-dev-qa-db-fra.com

Django requêtes - id vs pk

Lors de l'écriture de Django requêtes, on peut utiliser les deux id/pk comme paramètres de requête.

Object.objects.get(id=1)
Object.objects.get(pk=1)

Je sais que pk représente la clé primaire et n'est qu'un raccourci, selon la documentation de Django. Cependant, il n'est pas clair quand on devrait utiliser id ou pk.

djangoormprimary-key
180
Art

Ça n'a pas d'importance. pk est plus indépendant du champ de clé primaire actuel, c’est-à-dire que vous ne devez pas vous préoccuper de savoir si le champ de clé primaire s’appelle id ou object_id ou peu importe.

Cela vous donnera également plus de cohérence si vous avez des modèles avec différents champs de clé primaire.

196
Felix Kling

Dans Django projets où je sais que pk renvoie toujours id je préfère utiliser id lorsque cela ne se heurte pas à la fonction id() fonction (partout sauf les noms de variables). La raison en est que pk est une propriété 7 fois plus lente que id car il faut du temps pour rechercher pk nom d'attribut dans meta.

%timeit obj.id
46 ns ± 0.187 ns per loop (mean ± std. dev. of 7 runs, 10000000 loops each)
%timeit obj.pk
347 ns ± 11.3 ns per loop (mean ± std. dev. of 7 runs, 1000000 loops each)

Voici le code Django) pertinent:

def _get_pk_val(self, meta=None):
    meta = meta or self._meta
    return getattr(self, meta.pk.attname)

def _set_pk_val(self, value):
    return setattr(self, self._meta.pk.attname, value)

pk = property(_get_pk_val, _set_pk_val)

C'est vraiment un cas rare où j'ai besoin d'utiliser une variable nommée pk. Je préfère utiliser quelque chose de plus verbeux, comme user_id Au lieu de pk.

Suivre la même convention est préférable sur l’ensemble du projet. Dans votre cas, id est un nom de paramètre et non une propriété. Il n'y a donc pratiquement aucune différence de minutage. Les noms de paramètres n'entrent pas en conflit avec le nom de la fonction id() intégrée, il est donc prudent d'utiliser id ici.

Pour résumer, c'est à vous de choisir d'utiliser le nom de champ id ou le raccourci pk. Si vous ne développez pas de bibliothèque pour Django et utilisez champs de clé primaire automatique pour tous les modèles, vous pouvez utiliser id partout, ce qui est parfois plus rapide. Par contre, si vous voulez un accès universel à des champs de clé primaire (probablement personnalisés), utilisez pk partout. Un tiers de la microseconde n’est rien pour le Web.

12
utapyngo