Ctrl →

Nick2009 · Июль 6, 2009 15:45:09

Не могу найти в документации,
как определить в модели TYPE таблицы и ROW_FORMAT?

Александр Кошелев · Июль 6, 2009 16:09:35

http://docs.djangoproject.com/en/dev/ref/settings/#database-options

Nick2009 · Июль 6, 2009 16:22:35

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;

и т.п.

Отредактировано (Июль 6, 2009 16:23:06)

Александр Кошелев · Июль 6, 2009 16:56:07

Там вы можете задать дефолты для текущего коннекта.

Nick2009 · Июль 6, 2009 17:09:28

Daevaorn
Там вы можете задать дефолты для текущего коннекта.

Чем мне это поможет? Не понимаю. Поясните, пожалуйста, на примере.
Мне не дефолты нужны, а исключения из дефолтов.

Александр Кошелев · Июль 7, 2009 16:57:39

Nick2009
Чем мне это поможет? Не понимаю. Поясните, пожалуйста, на примере.

Вы можете задать дефолтные storage engine и row format для коннекта. И тогда все CREATE TABLE DDL запросы будут такими какие вам нужны.

Nick2009
Мне не дефолты нужны, а исключения из дефолтов.

Если это нужно только для части таблиц, то вы должны взять вывод:

./manage.py sqlall app

отредактировать под свои нужды и применить вручную.

Джанга DBMS-agnostic - поэтому специфичных для конкретных СУБД фич она не поддерживает (почти).

Nick2009 · Июль 8, 2009 16:47:01

Daevaorn
отредактировать под свои нужды и применить вручную.

Тогда уж лучше совсем это не использовать, ибо схема уже имеется. Задача, добиться совместимости модели и базы.

А как насчет построения индексов по нескольким полям? db_index=True не достаточно.

И еще. Как отключить все опции автоматического изменения имен таблиц и полей?
Способ объявления первичных ключей в Джанге не удобен для меня.
Очень геморно для каждой таблицы писать Meta и для каждого поля related_name

Daevaorn
Джанга DBMS-agnostic - поэтому специфичных для конкретных СУБД фич она не поддерживает (почти).

Большинство проектов реализуются в сжатые сроки под вполне конкретную СУБД, которая наилучшим образом отвечает концепции и требованиям проекта. Перевод проекта на другую СУБД обязательно связан с изменением концепции и схемы, что уже является новым проектом. Кроме того, разработчик может не часто менять свои предпочтения. Хотелось бы, чтобы агностицизм Джанги не мешал настривать проект под конкретную СУБД, тем более, от джанги много не требуется, всего лишь, обеспечить ручную настройку и не мешать разработчику. Пока, мне Джанга только мешает, много пока бесполезного кода, я не вижу в ближайшую неделю-две-три перспективы улучшения этой ситуации, т.к. проблемы нарастают а до сути проекта я еще не дошел.

Отредактировано (Июль 9, 2009 09:14:17)

Александр Кошелев · Июль 8, 2009 22:11:53

Nick2009
Тогда уж лучше совсем это не использовать, ибо схема уже имеется. Задача, добиться совместимости модели и базы.

Напишите просто комментарии, в которых укажите специфичные настройки для конкретной таблицы модели. Хоть как-то документируете.

Nick2009
А как насчет построения индексов по нескольким полям? db_index=True не достаточно.

db_index делает индекс только на одно поле. Для уникальных индексов на несколько полей есть мета опция unique_together. Неуникальные индексы на несколько полей объявить нельзя.

Nick2009
И еще. Как отключить все опции автоматического изменения имен таблиц и полей?

Изменение? Джанга ничего не меняет.

Nick2009
Способ объявления первичных ключей в Джанге не удобен для меня.

primary_key=True в конструкторе поля не удобно? Первичных ключей на несколько полей, пока нет.

Nick2009
Очень геморно для каждой таблицы писать Meta и для каждого поля related_name

Ну это пишется один раз и не должно особо напрягать. А related_name исключительно сахар для более “красивого” API использования связных моделей и тоже не так часто встречается.

Вообще Джанга сама может построить модели по имеющимся таблицам (конечно с учетом ограничений) http://docs.djangoproject.com/en/dev/ref/django-admin/#inspectdb

Nick2009 · Июль 9, 2009 06:51:15

Daevaorn

Как так, не меняет? Создает первичные ключи с именем id (а мне нужно своё имя), добавляет суффикс _id к FK (а мне нужно, чтобы имя поля осталось неизменным), добавляет префикс имени базы к имени каждой таблицы(а мне нужно, чтобы не добавляла). Для борьбы с этим приходится прибегать к различным ухищрениям. В результате код получается длиннее, менее читабельный и менее понятный чем просто SQL.

Кроме того, related_name не распознается как ключевое слово в конструкциях подобных этой, да и вообще не распознается в других встроенных классах.

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

а его добавление в определение класса мне совсем не нужно.

Напрягать не должно, но напрягает. Вот я и спрашиваю как эти опции отключить попроще?

Кроме того, я пока не нашел способ как победить Джанговское определение AutoField(), которое дает integer вместо integer unsigned
Либо как заставить PositiveIntegerField(primary_key=True) быть AUTO_INCREMENT

Отредактировано (Июль 9, 2009 08:34:27)

Александр Кошелев · Июль 9, 2009 09:42:12

Nick2009
Как так, не меняет? Создает первичные ключи с именем id (а мне нужно своё имя), добавляет суффикс _id к FK (а мне нужно, чтобы имя поля осталось неизменным), добавляет префикс имени базы к имени каждой таблицы(а мне нужно, чтобы не добавляла). Для борьбы с этим приходится прибегать к различным ухищрениям.

Это нельзя назвать изменением. Это правила транслирования DSL нотации на питоне в DDL базы данных. Но в любом случае, вы всегда можете указать явно как название конкретного поля - http://docs.djangoproject.com/en/dev/ref/models/fields/#db-column, так и таблицы - http://docs.djangoproject.com/en/dev/ref/models/options/#db-table.

Nick2009
Для борьбы с этим приходится прибегать к различным ухищрениям. В результате код получается длиннее, менее читабельный и менее понятный чем просто SQL.

Так если в лоб транслировать SQL в ORM конструкции, то зачастую получается плохой результат. Нужно пересматривать как архитектуру так и алгоритмы под новый инструмент.

Nick2009
Кроме того, related_name не распознается как ключевое слово в конструкциях подобных этой, да и вообще не распознается в других встроенных классах.

Как я уже говорил. related_name применяется только для нескольких типов полей - ForeignKey, ManyToManyField и OneToOneField. И это параметр никак не влияет на схему БД.

Nick2009
Кроме того, я пока не нашел способ как победить Джанговское определение AutoField(), которое дает integer вместо integer unsigned
Либо как заставить PositiveIntegerField(primary_key=True) быть AUTO_INCREMENT

Напишите свое поле.

А вообще очень рекомендую вам не бороться с Джангой. а просто отредактировать схему имеющейся базы данных к более django-friendly виду.

Python-сообщество

Уведомления

#1 Июль 6, 2009 15:45:09

Опции модели для MySQL

#2 Июль 6, 2009 16:09:35

Опции модели для MySQL

#3 Июль 6, 2009 16:22:35

Опции модели для MySQL

#4 Июль 6, 2009 16:56:07

Опции модели для MySQL

#5 Июль 6, 2009 17:09:28

Опции модели для MySQL

#6 Июль 7, 2009 16:57:39

Опции модели для MySQL

#7 Июль 8, 2009 16:47:01

Опции модели для MySQL

#8 Июль 8, 2009 22:11:53

Опции модели для MySQL

#9 Июль 9, 2009 06:51:15

Опции модели для MySQL

#10 Июль 9, 2009 09:42:12

Опции модели для MySQL

Board footer