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

2013-07-19 Thread 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

On Friday, 19 July 2013 23:45:06 UTC+10, Javier Guerra wrote:
>
> On Fri, Jul 19, 2013 at 4:26 AM, Tom Evans 
>  
> 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 
>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
For more options, visit https://groups.google.com/groups/opt_out.




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

2013-07-19 Thread Javier Guerra Giraldez
On Fri, Jul 19, 2013 at 4:26 AM, Tom Evans  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

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
For more options, visit https://groups.google.com/groups/opt_out.




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

2013-07-19 Thread Tom Evans
On Fri, Jul 19, 2013 at 2:31 AM, 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?
>

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

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
For more options, visit https://groups.google.com/groups/opt_out.




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

2013-07-18 Thread 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 ?

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
.
 >
 >

--
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+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
For more options, visit https://groups.google.com/groups/opt_out.




--
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+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
For more options, visit https://groups.google.com/groups/opt_out.




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

2013-07-18 Thread 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

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? 
>>
>> 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. 
>> > 
>> > 
>>
>>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
For more options, visit https://groups.google.com/groups/opt_out.




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

2013-07-18 Thread 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

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? 
>
> 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. 
> > 
> > 
>
>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
For more options, visit https://groups.google.com/groups/opt_out.




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

2013-07-18 Thread Mike Dewhirst

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?


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+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
For more options, visit https://groups.google.com/groups/opt_out.




--
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+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
For more options, visit https://groups.google.com/groups/opt_out.




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

2013-07-18 Thread 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

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
For more options, visit https://groups.google.com/groups/opt_out.