Dear Django Dev,

 

At Heroku, we have the privilege of seeing an extremely broad range of 
customers utilizing tools like Django to build their applications and 
companies. One of the things that we’ve seen customers hit, time and time 
again when using tools like Django, is integer overflows for primary keys. 
Their application starts behaving unpredictably once they reach the 
overflow, not even knowing such a constraint exists, and they often think 
the problem is with their database provider, rather than with their schema. 
Once they realize what is wrong, it’s a relatively trivial fix, but a 
migration can take several hours to complete, which results in unacceptable 
amounts of downtime.

 

Because of this, Heroku, as a company, would like to encourage bigints as a 
sane reasonable default for primary keys for application models. If the 
Django project agrees with this idea, that would mean that Django would 
provide BigAutoField as the default for ‘id’ instead of AutoField. 

 

Rails made this change recently 
<http://www.mccartie.com/2016/12/05/rails-5.1.html>, and has seen success 
in doing so. 

 

I’m happy to provide the code to do this, but I wanted to discuss it here 
before doing so, to hear what the general consensus was to the proposal of 
such a change. 

 

 

Pros:

   - 
   
   Users of Django, following the docs, won’t accidentally hit the int 
   overflow barrier. 
   - 
   
   Encourages best-practices from the beginning. 
   - 
   
   Bigints don’t take up much more storage than ints when using Postgres. 
   - 
   
   In-line with other frameworks moving forward on this issue, like Rails 
   <http://www.mccartie.com/2016/12/05/rails-5.1.html>.
   
 

Cons:

   - 
   
   Backwards compatibility would need to be considered. 
   
 
Why not UUID?

 

I agree! I love using UUID for my primary keys, and I think a patch to 
Django which provides an AutoUUIDField would be wonderful. However, there 
are a few major drawbacks to making this the new default:

 

   1. 
   
   It’s confusing to new users, would make onboarding process more 
   difficult. 
   2. 
   
   UUID is difficult to implement in MySQL. 
   3. 
   
   UUID has larger storage requirements. 
   4. 
   
   Incrementing IDs are actually useful. 
   
 


So, my proposal is to simply lift the int barrier to a bigint barrier for 
new Django applications, and I think it will save a lot of developers a lot 
of pain in the long run. 

 

Many thanks,

 

Kenneth Reitz

Heroku Python

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/6fe3401c-4404-4bd8-9d22-58df95cd1348%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to