Не могу найти в документации,
как определить в модели TYPE таблицы и ROW_FORMAT?
DaevaornИ где там об этом?
http://docs.djangoproject.com/en/dev/ref/settings/#database-options
CREATE TABLE static(...) TYPE=MYISAM ROW_FORMAT=fixed;
CREATE TABLE dinamic(...) TYPE=InnoDB ROW_FORMAT=fixed;
DaevaornЧем мне это поможет? Не понимаю. Поясните, пожалуйста, на примере.
Там вы можете задать дефолты для текущего коннекта.
Nick2009Вы можете задать дефолтные storage engine и row format для коннекта. И тогда все CREATE TABLE DDL запросы будут такими какие вам нужны.
Чем мне это поможет? Не понимаю. Поясните, пожалуйста, на примере.
Nick2009Если это нужно только для части таблиц, то вы должны взять вывод:
Мне не дефолты нужны, а исключения из дефолтов.
./manage.py sqlall app
DaevaornТогда уж лучше совсем это не использовать, ибо схема уже имеется. Задача, добиться совместимости модели и базы.
отредактировать под свои нужды и применить вручную.
DaevaornБольшинство проектов реализуются в сжатые сроки под вполне конкретную СУБД, которая наилучшим образом отвечает концепции и требованиям проекта. Перевод проекта на другую СУБД обязательно связан с изменением концепции и схемы, что уже является новым проектом. Кроме того, разработчик может не часто менять свои предпочтения. Хотелось бы, чтобы агностицизм Джанги не мешал настривать проект под конкретную СУБД, тем более, от джанги много не требуется, всего лишь, обеспечить ручную настройку и не мешать разработчику. Пока, мне Джанга только мешает, много пока бесполезного кода, я не вижу в ближайшую неделю-две-три перспективы улучшения этой ситуации, т.к. проблемы нарастают а до сути проекта я еще не дошел.
Джанга DBMS-agnostic - поэтому специфичных для конкретных СУБД фич она не поддерживает (почти).
Nick2009Напишите просто комментарии, в которых укажите специфичные настройки для конкретной таблицы модели. Хоть как-то документируете.
Тогда уж лучше совсем это не использовать, ибо схема уже имеется. Задача, добиться совместимости модели и базы.
Nick2009db_index делает индекс только на одно поле. Для уникальных индексов на несколько полей есть мета опция unique_together. Неуникальные индексы на несколько полей объявить нельзя.
А как насчет построения индексов по нескольким полям? db_index=True не достаточно.
Nick2009Изменение? Джанга ничего не меняет.
И еще. Как отключить все опции автоматического изменения имен таблиц и полей?
Nick2009primary_key=True в конструкторе поля не удобно? Первичных ключей на несколько полей, пока нет.
Способ объявления первичных ключей в Джанге не удобен для меня.
Nick2009Ну это пишется один раз и не должно особо напрягать. А related_name исключительно сахар для более “красивого” API использования связных моделей и тоже не так часто встречается.
Очень геморно для каждой таблицы писать Meta и для каждого поля related_name
DaevaornКак так, не меняет? Создает первичные ключи с именем id (а мне нужно своё имя), добавляет суффикс _id к FK (а мне нужно, чтобы имя поля осталось неизменным), добавляет префикс имени базы к имени каждой таблицы(а мне нужно, чтобы не добавляла). Для борьбы с этим приходится прибегать к различным ухищрениям. В результате код получается длиннее, менее читабельный и менее понятный чем просто SQL.
class FixCharField(models.Field):
def __init__(self, max_length, *args, **kwargs):
self.max_length = max_length
super(FixCharField, self).__init__(*args, **kwargs)
def db_type(self):
return 'char(%s)' % self.max_length
Nick2009Это нельзя назвать изменением. Это правила транслирования DSL нотации на питоне в DDL базы данных. Но в любом случае, вы всегда можете указать явно как название конкретного поля - http://docs.djangoproject.com/en/dev/ref/models/fields/#db-column, так и таблицы - http://docs.djangoproject.com/en/dev/ref/models/options/#db-table.
Как так, не меняет? Создает первичные ключи с именем id (а мне нужно своё имя), добавляет суффикс _id к FK (а мне нужно, чтобы имя поля осталось неизменным), добавляет префикс имени базы к имени каждой таблицы(а мне нужно, чтобы не добавляла). Для борьбы с этим приходится прибегать к различным ухищрениям.
Nick2009Так если в лоб транслировать SQL в ORM конструкции, то зачастую получается плохой результат. Нужно пересматривать как архитектуру так и алгоритмы под новый инструмент.
Для борьбы с этим приходится прибегать к различным ухищрениям. В результате код получается длиннее, менее читабельный и менее понятный чем просто SQL.
Nick2009Как я уже говорил. related_name применяется только для нескольких типов полей - ForeignKey, ManyToManyField и OneToOneField. И это параметр никак не влияет на схему БД.
Кроме того, related_name не распознается как ключевое слово в конструкциях подобных этой, да и вообще не распознается в других встроенных классах.
Nick2009Напишите свое поле.
Кроме того, я пока не нашел способ как победить Джанговское определение AutoField(), которое дает integer вместо integer unsigned
Либо как заставить PositiveIntegerField(primary_key=True) быть AUTO_INCREMENT