Requêtes Django - id vs pk

Question

Lors de l'écriture de requêtes django, 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 est l'abréviation de Primary Key et qu'il s'agit simplement d'un raccourci, selon la documentation de django. Cependant, il n'est pas clair quand on doit utiliser id ou pk.

Answer 1

Ça n'a pas d'importance. pk est plus indépendant du champ clé primaire réel, c'est-à-dire que vous n'avez pas besoin de vous préoccuper de savoir si le champ clé primaire s'appelle id o object_id ou autre.

Il assure également une plus grande cohérence si vous avez des modèles avec des champs de clé primaire différents.

Answer 2

Dans les projets Django où je sais que pk retourne toujours id Je préfère utiliser id lorsqu'il n'entre pas en conflit avec le id() (partout sauf pour les noms de variables). La raison en est que pk est une propriété qui est 7 fois plus lente que id puisque cela prend du temps de chercher pk nom de l'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 correspondant :

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 explicite, comme user_id au lieu de pk .

Il est préférable de suivre la même convention pour l'ensemble du projet. Dans votre cas id est un nom de paramètre, pas une propriété, il n'y a donc pratiquement aucune différence dans les délais. Les noms des paramètres n'entrent pas en conflit avec le nom des propriétés intégrées. id() il est donc possible d'utiliser la fonction id ici.

En résumé, c'est à vous de choisir d'utiliser ou non le nom de champ id ou le pk raccourci. Si vous ne développez pas de bibliothèque pour Django et que vous utilisez la fonction champs de clé primaire automatique pour tous les modèles, il est sûr d'utiliser id partout, ce qui est parfois plus rapide. D'un autre côté, si vous voulez un accès universel aux champs de clé primaire (probablement personnalisés), utilisez alors pk partout. Un tiers de microseconde n'est rien pour le web.