liuyang1520 / django-command-extensions

Automatically exported from code.google.com/p/django-command-extensions
MIT License
0 stars 0 forks source link

sqldiff strips auto_increment from bigint primary keys #108

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago
We use BigAutoField as our primary key ids from here: 
http://www.djangosnippets.org/snippets/1244/

When using sqldiff, it suggests:

ALTER TABLE <table> MODIFY `id` bigint;

for every table in the database that uses them. Running its suggestions strips 
AUTO_INCREMENT 
from all our fields. This of course breaks adding new rows. Interestingly, if 
you run it and then do 
sqldiff again, it still suggests these changes even though it has already made 
them.

Original issue reported on code.google.com by physicsn...@gmail.com on 7 Jul 2009 at 8:26

GoogleCodeExporter commented 8 years ago
As your saying AUTO_INCREMENT I'm assuming your using mysql.

I hope somebody can write up a patch for this.
As I write in the source of sqldiff there are a lot of known issues with MySQL:

- MySQL has by far the most problems with introspection. Please be carefull when
using MySQL with sqldiff. 
   - Booleans are reported back as Integers, so there's know way to know if there was
a real change.
   - Varchar sizes are reported back without unicode support so there size may change
in comparison to the real length of the varchar.   
   - Some of the 'fixes' to counter these problems might create false positives or
false negatives.

I've added 'bigint' to the types in sqldiff which need an AUTO_INCREMENT if 
there
also a primary key. Hopefully this works, however since Django's MySQL database
backend doesn't support bigint and I don't have MySQL to test this I'm not sure 
about
that.

Please test this with the latest version from github.
http://github.com/django-extensions/django-extensions/commit/309f9b61f09a6273ff7
8e93b98a0d9008a9f77a2

Original comment by v.oostv...@gmail.com on 16 Jul 2009 at 10:23

GoogleCodeExporter commented 8 years ago
I put this comment on the actual change - should be here:

Why check db_type at all?  That seems unnecessary and leaves open the 
possibility of tinyint failing or 
something.

Original comment by arocki...@gmail.com on 20 Jul 2009 at 10:16

GoogleCodeExporter commented 8 years ago
It's been awhile, and my head is filled with other code at the moment.

But db_type also checks changes the other way around.

Where you did a ALTER TABLE foo ALTER COLUMN foo_field TYPE bigint;
Now sqldiff should detect that 'foo_field' is an integer in your django models 
and a
bigint in the database.

Is this what you mean ?
(btw did the above patch work ?)

Original comment by v.oostv...@gmail.com on 23 Jul 2009 at 1:24

GoogleCodeExporter commented 8 years ago
I haven't bothered to test it but it would probably work. As someone else 
commented though it looks like a hack 
solution. It's pretty useless now anyway since on trunk sqldiff refuses to 
output SQL commands for MySQL now. 
It just tells me the differences, which is kind of useless since on development 
I already know the differences and 
on server I can just diff the table definitions from a dump.

Original comment by physicsn...@gmail.com on 17 Aug 2009 at 8:54