Domande Django - id vs pk

203

Quando si scrivono query django si possono usare sia id / pk come parametri di query.

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

So che pk sta per chiave primaria ed è solo una scorciatoia, secondo la documentazione di Django. Tuttavia non è chiaro quando si dovrebbe usare id o pk.

django orm primary-key

— Arte
fonte

Ecco la rispettiva documentazione: a favoreid e perpk

— Lutz Prechelt del

Possibile duplicato di Qual è la differenza tra Model.id e Model.pk in django?

— Travis,

Vuoi sapere se c'è qualcosa di più docs.djangoproject.com/en/1.11/topics/db/queries/…

— Rajan Chauhan

Controlla qui la versione aggiornata docs.djangoproject.com/en/2.2/topics/db/models/…

— Tessaracter

224

Non importa pkè più indipendente dal campo di chiave primaria effettiva cioè che non è necessario per la cura se il campo chiave primaria si chiama ido di object_ido qualsiasi altra cosa.

Fornisce inoltre maggiore coerenza se si hanno modelli con campi chiave primaria diversi.

— Felix Kling
fonte

34

Sì. Usa solo pk. Sempre.

— cethegeek,

47

idè anche una funzione integrata in Python, per questo preferisco usare pk.

— Thierry Lam,

5

Sì, pkè preferibile. Vedi la documentazione della funzione integrataid nella libreria standard di Python. (È lo stesso in Python 2. )

— Lutz Prechelt il

26

Nei progetti Django in cui so che pkritorna sempre idpreferisco usare idquando non si scontrano con la id()funzione (ovunque tranne i nomi delle variabili). La ragione di ciò è che pkè una proprietà che è 7 volte più lenta di da idquando ci vuole tempo per cercare il pknome dell'attributo 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)

Ecco il codice Django pertinente:

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)

È davvero un caso raro quando devo usare una variabile chiamata pk. Preferisco usare qualcosa di più dettagliato, come user_idinvece di pk.

Seguire la stessa convenzione è preferibile in tutto il progetto. Nel tuo caso idè un nome di parametro, non una proprietà, quindi non c'è quasi alcuna differenza nei tempi. I nomi dei parametri non si scontrano con il nome della id()funzione integrata, quindi è sicuro utilizzarli idqui.

Per riassumere, spetta a te scegliere se utilizzare il nome del campo ido il pkcollegamento. Se non stai sviluppando una libreria per Django e utilizzi i campi chiave primaria automatici per tutti i modelli, è sicuro da usare idovunque, che a volte è più veloce. D'altra parte, se si desidera l'accesso universale a campi chiave primari (probabilmente personalizzati), utilizzare pkovunque. Un terzo di un microsecondo non è nulla per il web.

— utapyngo
fonte