Best practice - using Django model's in-built id field?

[Victor Hooi]

Hi,

I'm just wondering - is it considered good or bad practice to use a Django model's in-built ID field?

Say for example you wanted a unique identifier for each transactio - should you be generating your own, or can you use just self.id?

Cheers,

Victor

[Mike Dewhirst]

Don't go there. Generate your own. Consider what might happen if you
needed to migrate to a different database or platform. The id integer
will be a nightmare to manage so the unique transactions retain their
original numbers.

Mike


>
> Cheers,
> Victor
>
> --
> You received this message because you are subscribed to the Google
> Groups "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to django-users...@googlegroups.com.
> To post to this group, send email to django...@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-users.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[Victor Hooi]

Hi,

Ok, thanks, I'll generate my own AutoField to track each transaction.

Just to clarify - when you say they'll be issues with migration, what do you mean? Is it because that field is also as a FK to other models? Or something else?

Cheers,

Victor

[Victor Hooi]

Hi,

Actually, while we're there - is this a suitable use of AutoField? Or is there a better way to generate unique transactions IDs? python.uuid? Or something better?

Cheers,

Victor

[Mike Dewhirst]

On 19/07/2013 12:05pm, Victor Hooi wrote:
> Hi,
>
> Actually, while we're there - is this a suitable use of AutoField? Or is
> there a better way to generate unique transactions IDs? python.uuid? Or
> something better?

It depends on your use-case.

If your unique transaction number requirement is only short term, for
example delivery tracking, you can almost guarantee it doesn't matter if
you restart the numbering in future then you *could* use the id.

It only really matters if there is money and accounting involved. That
is where most of my experience has been. Hence my own "rule" to never
use a PK for transaction numbers. I have generally used a singleton
method which saves its state on receiving a close signal.

Autofield is good if you are comfortable managing restoration from
backup so your next transaction number satisfies your own business
rules. Sometimes it matters whether such numbers are really sequential.
If so and you can't tweak the next number you might have to perform
dummy transactions until the numbers satisfy you.

If you build your own generator you need something which doesn't prove
to be a bottleneck when your system scales up.

python.uuid solves such problems but may not suit your needs.

hth

Mike

>
> Cheers,
> Victor
>
> On Friday, 19 July 2013 11:57:21 UTC+10, Victor Hooi wrote:
>
> Hi,
>
> Ok, thanks, I'll generate my own AutoField to track each transaction.
>
> Just to clarify - when you say they'll be issues with migration,
> what do you mean? Is it because that field is also as a FK to other
> models? Or something else?
>
> Cheers,
> Victor
>
> On Friday, 19 July 2013 11:50:25 UTC+10, Mike Dewhirst wrote:
>
> On 19/07/2013 11:31am, Victor Hooi wrote:
> > Hi,
> >
> > I'm just wondering - is it considered good or bad practice to
> use a
> > Django model's in-built ID field?
> >
> > Say for example you wanted a unique identifier for each
> transactio -
> > should you be generating your own, or can you use just

> self.id <http://self.id>?

>
> Don't go there. Generate your own. Consider what might happen if
> you
> needed to migrate to a different database or platform. The id
> integer
> will be a nightmare to manage so the unique transactions retain
> their
> original numbers.
>
> Mike
>
>
> >
> > Cheers,
> > Victor
> >
> > --
> > You received this message because you are subscribed to the
> Google
> > Groups "Django users" group.
> > To unsubscribe from this group and stop receiving emails from
> it, send
> > an email to django-users...@googlegroups.com.
> > To post to this group, send email to django...@googlegroups.com.
> > Visit this group at
> http://groups.google.com/group/django-users

> <http://groups.google.com/group/django-users>.

> > For more options, visit
> https://groups.google.com/groups/opt_out

> <https://groups.google.com/groups/opt_out>.

[Tom Evans]

The problem with using an auto increment field for a unique identifier
is that the values are easily guessable. You are better off adding a
uuid field and either using it as the primary key, or adding it as a
unique key and keeping id as the pk.

The other question is how to store the uuid, which is a 128 bit
number. Most databases don't support such large numbers, and so Django
doesn't provide a UUIDField. You can always store the uuid in 36
(iirc) text characters, but that makes lookups slightly less
efficient. If you use the uuid as the primary key, and you are using a
text field to store it in, then any object that has a foreign key to
this object will also need a 36 character uuid column - ie there is a
cost to having it as the primary key.

Because of this, I usually add a uuid field as a unique key, but leave
id as the primary key.

Cheers

Tom

[Javier Guerra Giraldez]

On Fri, Jul 19, 2013 at 4:26 AM, Tom Evans <teva...@googlemail.com> wrote:
> Because of this, I usually add a uuid field as a unique key, but leave
> id as the primary key.

same here.

but only for those tables whose records would be seen by the public.
kinda like 'slugs for non-textual objects'

--
Javier

[Victor Hooi]

Hi,

Funny you guys should mention that =), after Mike's post, I ended up just using David Cramer's django-uuidfield (https://github.com/dcramer/django-uuidfield) package.

(There's also django-shortuuidfield - https://github.com/nebstrebor/django-shortuuidfield).

For Postgres, this uses the uuid type - http://www.postgresql.org/docs/9.1/static/datatype-uuid.html).

This also sets unique=True - not sure what happens if there's a collision, I assume it just won't create that one.

The only thing I was concerned about was a performance hit from calculating the UUID for each transaction, however, I suspect that's something I don't need to worry about until down the track.

Cheers,

Victor