Here is the construction:

sbSorterTree = models.CharField( max_length=64, blank=True, default="" unique=False, db_index=True, verbose_name=u"Сортировщик деревьев", help_text=u"Служебное поле" )

Creates the following field:

 sbSorterTree varchar(64) NOT NULL

But you need to create:

 sbSorterTree varchar(64) BINARY NOT NULL

How to do this? Actually, the task is to make the index by field be built on the principle of a text field (i.e. "124" in sorting before "89") and arbitrary characters (even unreadable) could be written to it and the register did not affect sorting.

    2 answers 2

    Write your own field

     class BinaryCharField(models.CharField): def db_type(self, connection): return super(BinaryCharField, self).db_type(connection) + ' binary' sbSorterTree = models.BinaryCharField( # ... )

    The result is sql:

     ADD COLUMN "test" varchar(64) binary;

    That is, the goal is achieved

    The sbSorterTree field added to the ExampleTable model

     class ExampleTable(models.Model): sbSorterTree = models.CharField(max_length=64, blank=True, default="", unique=False, db_index=True, verbose_name=u"Сортировщик деревьев", help_text=u"Служебное поле") class Meta: db_table = 'example_table'

    creates such a migration:

     class Migration(migrations.Migration): dependencies = [ ... ] operations = [ migrations.CreateModel( name='ExampleTable', fields=[ ('id', models.AutoField(auto_created=True, primary_key=True, serialize=False, verbose_name='ID')), ('sbSorterTree', models.CharField(blank=True, db_index=True, default='', help_text='Служебное поле', max_length=64, verbose_name='Сортировщик деревьев')), ], options={ 'db_table': 'example_table', }, ), ]

    and such sql:

     BEGIN; -- -- Create model ExampleTable -- CREATE TABLE `example_table` (`id` integer AUTO_INCREMENT NOT NULL PRIMARY KEY, `sbSorterTree` varchar(64) NOT NULL); CREATE INDEX `example_table_479ea2e4` ON `example_table` (`sbSorterTree`); COMMIT;

    You can add a RunSQL command to the migration file and replicate, for example:

     class Migration(migrations.Migration): dependencies = [ ... ] operations = [ migrations.CreateModel( name='ExampleTable', fields=[ ('id', models.AutoField(auto_created=True, primary_key=True, serialize=False, verbose_name='ID')), ('sbSorterTree', models.CharField(blank=True, db_index=True, default='', help_text='Служебное поле', max_length=64, verbose_name='Сортировщик деревьев')), ], options={ 'db_table': 'example_table', }, ), migrations.RunSQL("ALTER TABLE example_table MODIFY COLUMN sbSorterTree varchar(64) BINARY NOT NULL;"), ]
    • I understand that this is not sporty, but is it not easier then to get into the base with your hands and through the ALTER TABLE to assign the BINARY field? Django will not notice anything (she doesn’t care), but everything will work as planned ... - erjemin
    • I prefer to do it through RunSQL so that there is a history and, for example, an inexperienced developer could fulfill these queries as part of a migration on a local project. - bilabon