Greetings,
as per documentation on Model field reference | Django documentation | Django
BigAutoField
BigAutoField ( **options )[¶]except that it is guaranteed to fit numbers from 1 to 9223372036854775807 .
It created in Mysql this
bigint which is
A large integer. The signed range is -9223372036854775808 to 9223372036854775807
id = models.BigAutoField(primary_key=True)
Any ides how can i make positive bigautofield only?
Django’s autoincrement behaviour will only use the positive numbers by default.
If you’re concerned about accidental insertion of negative values, you can subclass the field or use a check constraint to limit the range as per my related blog post.
Hi, i am not much concerned about negative numbers but rather correct implementation for migration and syncdb. As it is not correct.
I don’t understand in what way it is not correct.
Django promises to fit at least the numbers 1 to 9223372036854775807. That 0 and negative numbers are supported is an extension.
Okay, lets say i want 0-65535
smallint unsigned on mysql.
How can i achieve that?
With 2 Storage (Bytes) as per mysql documentation smallint unsigned.
Correct me if i’m wrong but the empty cells still consume storage in DB.
So if we have
1 to 9223372036854775807
or
-9223372036854775808to9223372036854775807
It is 2x the difference in storage space.
Ok, you’re wrong.
1 to 9223372036854775807 - requires 63 bits.
-9223372036854775808 to 9223372036854775807 - uses 64 bits.
In either case, an instance of that field is going to be stored in 64 bits.
If you’re working with a 64-bit unsigned value (instead of a two’s complement integer), the range would be 0 to 18446744073709551615.
Ken is right that there’s no space saving from unsigned vs signed.
To use an autofield with small unsigned integers you’ll want to use a subclass. But it’s not a good idea.
The reason Django moved its default from 32 bit to 64 bit is the danger of ID exhaustion - running out of autoincrement ID’s. This typically takes down a site until its database can be migrated - several large companies have had large outages because of this, e.g. Basecamp and Sentry.
If you’re looking for the storage savings from using 2 bytes instead of 8 - they’re really small compared to the cost of storage. The tradeoff will basically never be worth it.
You’ll realize much larger storage savings using a compressed database format e.g. PostgreSQL on ZFS or MariaDB’s table compression. This will compress all your data, not just the autoincrement column, and can save you a bunch of disk space.
Thank you guyz! Got it.
But is it okay that django is automatking on mysql column with bigint and not bigint unassigned?
Then its not 64bits?!
Different question then, what should i do so that django model will create bigint unassigned?
(emphasis added)
To answer your other question, you don’t - nor should you worry about it. It will never become a problem.