Портал Python-программистов

securelord написал:

Вопрос - как в models.py использовать к примеру InnoDB заместо Myisam?

это не предусмотрено

securelord написал:

Как Django работает с уже существующей базой и таблицами?

так же как и обычно. надо просто создать модели соответствующие таблицам - можно сделать автоматически

securelord написал:

Как в models.ForeignKey() выставлять правила обновления по delete и update?

поподробнее, что хочешь сделать

Daevaorn написал:

поподробнее, что хочешь сделать

что то вроде этого.
[code sql]create table users (
        id_user int() not null auto_increment,
    id_party int() not null,
    Primary key (id_user)
    Foreign key (id_party) references party(id_party)
        on delete cascade
        on update cascade
                                         )
[/code]
Или эти своиства по умолчанию?

Daevaorn написал:

так же как и обычно. надо просто создать модели соответствующие таблицам - можно сделать автоматически

А как быть со сложными запросами? Или пользоваться курсорами?

Отредактированно securelord (2007-12-04 19:07:19)

securelord написал:

что то вроде этого.

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

securelord написал:

А как быть со сложными запросами? Или пользоваться курсорами?

что-то через ORM, что-то через курсор. Выбирай по ситуации.

Спасибо

securelord написал:

Вопрос - как в models.py использовать к примеру InnoDB заместо Myisam?

В models.py никак, но в settings.py можно задать DATABASE_OPTIONS = {"init_command": "SET storage_engine=INNODB" }. http://code.djangoproject.com/svn/djang … abases.txt

А еще где то был howto как уговорить джангу самостоятельно попробовать превратить существующую БД в джанго-модели. Было в документации в районе Database API / Models API

Отредактированно Lolka (2008-01-02 13:10:07)

Lolka написал:

А еще где то был howto как уговорить джангу самостоятельно попробовать превратить существующую БД в джанго-модели.

http://www.djangoproject.com/documentat … #inspectdb

А потом как работать? Как организовать цикл развития ПО?

Допустим, мы начинаем разработку с
1) ER-диаграммы на логическом уровне (одна модель для любой СУБД)
2) Получаем SQL код №1 для нескольких СУБД
3) Если не удается добиться нужной генерации, правим специфику в редакторе, фиксируем различие, документируем №1 для нескольких СУБД.
4) Генерим БД №1 на нескольких СУБД.
----
5) Импортируем схему БД в models.py №1 с самой дружественной СУБД (допустим 50 сущностей, а вдруг)
6) Добавляем по шаблону всем стандартный дополнительный питоновский код
7) Добавляем некоторым ручками некоторый специальный код
8) Проверяем совместимость модели №1 с базами данных №1 на нескольких СУБД.
----
9) Решаем изменить логическую схему, вносим изменение в ER (п.1)

Повторяем шаги 1 - 8 для №2, а потом пишем процедуру импорта данных из №1 в №2 для каждой СУБД

При этом мы каждый раз будем повторять одинаковую ручную работу на этапах 2 и особенно 6 и 7
Функционал Django для автоматической генерации баз данных и синхронизации почти совсем не используем.

Или есть другие варианты?
Я правда не могу решить как правильно организовать процесс разработки.

ps.Странно, что в Django нет Визуального дизайнера для models.

PyCraft написал:

При этом мы каждый раз будем повторять одинаковую ручную работу на этапах 2 и особенно 6 и 7

Так автоматизируйте. Что мешает?

PyCraft написал:

Я правда не могу решить как правильно организовать процесс разработки.

Модель первична.

PyCraft написал:

Странно, что в Django нет Визуального дизайнера для models.

Куда уж визуальнее и функциональнее чем имеющийся DSL?

И лучше было бы создать отдельную тему.

Daevaorn написал:

Так автоматизируйте. Что мешает?

Это отдельная большая(лишняя) работа и не понятно как это автоматизировать.

Daevaorn написал:

Модель первична.

Понятно, но какая Объектная(Models.py) или Логическая(ER)
От чего плясать, от диаграммы к питону или от питона к диаграмме?

Daevaorn написал:

Куда уж визуальнее и функциональнее чем имеющийся DSL?

а это что такое, Domain-Specific Language для шаблонов генерации HTML, или что-то иное?

Согласен, перенести бы часть ветки в отдельную тему, начиная от моего первого поста.

PyCraft написал:

Это отдельная большая(лишняя) работа и не понятно как это автоматизировать.

Но, если очень нужно, то некую рутину всегда можно сократить.

PyCraft написал:

Понятно, но какая Объектная(Models.py) или Логическая(ER)

Models.py

PyCraft написал:

От чего плясать, от диаграммы к питону или от питона к диаграмме?

От питона к питону. Зачем плодить сущности, если питон сам очень хорошо для прототипирования и само-документирования?

PyCraft написал:

Domain-Specific Language

Именно. Само описание джанго модели максимально визуально и функционально.

Отредактированно Daevaorn (2008-06-10 20:19:23)

Ничего не имею против Python и Django ибо первый нравится, а второй люди делали для себя, а не для меня. Однако, не разделяю Вашего оптимизма по поводу их идеальности для моделирования данных. Они для этого совсем не предназначены. Для этого существуют специальные средства (IDEF,UML) Графические примитивы всяко нагляднее и проще, чем модели в Django. По крайней мере для меня, а я именно для себя ищу инструмент. Если бы в Django был такой визуальный инструмент, напрямую работающий с кодом модели Django(а не с моделью базы данных) то это было бы намного удобнее чем городить описанную выше цепочку. Технически это совсем не сложно реализовать даже студенту(намного намного проще, чем то что понаделано), поэтому я и удивился почему его нет в базовой версии. Просто не нужен был, задачи БД были простые, не досмотрели. Нужное подчеркнуть

PyCraft написал:

Вашего оптимизма по поводу их идеальности для моделирования данных. Они для этого совсем не предназначены. Для этого существуют специальные средства (IDEF,UML)

Django это Agile в чистом виде. И лишние артефакты ему не нужны.
Идея, короткое совещание в команде и реализация. Что-то не так, быстрое изменение и опять проверка результатов.
Никаких больших подготовительных этапов. То что вы предлагаете, это  overenginiring в чистом виде, применительно к проекту на Django.

PyCraft написал:

Графические примитивы всяко нагляднее и проще, чем модели в Django. По крайней мере для меня, а я именно для себя ищу инструмент.

Я видел уже достаточное количество людей, которые пытались писать на Django, но не желали отбросить старые паттерны мышления и свой прошлый опыт, который не применим тут. И либо они всё-таки начинали думать в правильном русле и постепенно понимать смысл и толк Django, либо бросали всё, так и не осознав.

PyCraft написал:

сли бы в Django был такой визуальный инструмент, напрямую работающий с кодом модели Django(а не с моделью базы данных) то это было бы намного удобнее чем городить описанную выше цепочку. Технически это совсем не сложно реализовать даже студенту(намного намного проще, чем то что понаделано), поэтому я и удивился почему его нет в базовой версии.

Разработчики Django не являются разработчиками языков программирования (о чем они декларируют сразу), также они не разработчики, к счастью, всяких сомнительно полезных гуевых приблуд. Уж лучше пусть они время тратят на дело.
DSL представление джанги максимально визуально и практично.

PyCraft написал:

Просто не нужен был, задачи БД были простые, не досмотрели. Нужное подчеркнуть

Работая с Django, вы о БД должны думать в последнюю очередь. Ваша задача - придумать модель данных и реализовать её в виде классов. Какой бекэнд хранения у них, это уже вторично. Может быть это вообще не реляционная БД? Вы же всё хотите перевернуть с ног на голову.

Daevaorn написал:

Работая с Django, вы о БД должны думать в последнюю очередь. Ваша задача - придумать модель данных и реализовать её в виде классов. Какой бекэнд хранения у них, это уже вторично. Может быть это вообще не реляционная БД? Вы же всё хотите перевернуть с ног на голову.

Интересно, ка Вы предлагаете "придумать модель данных"(или упаси боже "Знаний"), когда количество сущностей начинает превышать 7, я уж не говорю про 70, когда удержать всю модель в голове, со всеми ее связями и ограничениями целостности, и тем более воспринять ее визуально из кода становится проблематично и не важно какой это код Django или SQL. С последним даже проще будет, т.к. не нужно в уме преобразоввывать типы полей Django к типам SQL, но даже он не годится. Django отличный инструмет для создания сайтов или даже многозвенных приложений, но не моделирования данных. Модели там предназначены для упрощения программного доступа и управления данными, а не для концептуального, информационного или логического моделирования, и тем более не для визуального представления.
Врядли стоит отказываться от фундаментальных концепций моделирования данных в пользу прикладного инструмента который по словам самих авторов не имел никакой фундаментальной базы, а был разработан чисто из практических соображений с единственной целью - упростить и ускорить их работу. Они с этим справились отлично, так что хвала им и Джанге, но без фанатизма.

PyCraft написал:

когда количество сущностей начинает превышать 7, я уж не говорю про 70

Тогда вы ошиблись с выбором Django, как инструмента.

PyCraft написал:

Django отличный инструмет для создания сайтов или даже многозвенных приложений, но не моделирования данных.

Безусловно, в том моделировании,  в котором нуждается проект на джанго, он (DSL) справляется.

PyCraft написал:

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

Вторая часть тезиса противоречит первой. За счет отсутствия необходимости долгого моделирования и проектирования, достигается упрощение и ускорение.

Daevaorn написал:

Вторая часть тезиса противоречит первой. За счет отсутствия необходимости долгого моделирования и проектирования, достигается упрощение и ускорение.

Противоречия нет, есть Ваша трактовка. Моя трактовка в том, что упрощение и ускорение достигается за счет отказа от моделирования, а не за счет его ненужности. Просто так быстрее выполнить заказ, показать товар лицом и получить вознаграждение. Более того, когда в скором времени вскроется отсутствие чего-то или функциональность окажется не такой какая ожидалась, это на руку разработчику, всегда можно ткнуть заказчика мордой в ТЗ и попросить еще денег на доработку. Выгодно? Несомненно. Юридически грамотно? Бесспорно. Но плохо пахнет и не для всех подходит.

Для цели побыстрее заработать денег, лучше не придумаешь.
Ремесло, одним словом. При таком подходе, ни о каких высоких технологиях и науке речи быть не может.
Только "штучки" и "прибамбасы", которые можно быстро обсудить и изготовить. Типа "отправь SMS сообщение на номер 999 и выиграй миллион".
Лично я пытаюсь применить Django по его  назначению, но в рамках фундаментального проекта и мне без моделирования не обойтись.
Если без моделирования и глубокого продумывания, то потом переделывать самому боком выйдет.

Daevaorn написал:

Тогда вы ошиблись с выбором Django, как инструмента.

Неужели только < 7 и только плоские таблицы без оптимизации? Может это Вы ошиблись?

Отредактированно PyCraft (2008-06-11 13:53:17)

PyCraft написал:

Противоречия нет, есть Ваша трактовка. Моя трактовка в том, что упрощение и ускорение достигается за счет отказа от моделирования, а не за счет его ненужности. Просто так быстрее выполнить заказ, показать товар лицом и получить вознаграждение. Более того, когда в скором времени вскроется отсутствие чего-то или функциональность окажется не такой какая ожидалась, это на руку разработчику, всегда можно ткнуть заказчика мордой в ТЗ и попросить еще денег на доработку. Выгодно? Несомненно. Юридически грамотно? Бесспорно. Но плохо пахнет и не для всех подходит.

Для цели побыстрее заработать денег, лучше не придумаешь.
Ремесло, одним словом. При таком подходе, ни о каких высоких технологиях и науке речи быть не может.
Только "штучки" и "прибамбасы", которые можно быстро обсудить и изготовить. Типа "отправь SMS сообщение на номер 999 и выиграй миллион".
Лично я пытаюсь применить Django по его  назначению, но в рамках фундаментального проекта и мне без моделирования не обойтись.

Что-то это вас совсем унесло не в ту степь. Разглагольстовать все умеют. Только в на веб-морду их не повесишь и сервис клиентам не предоставишь.

PyCraft написал:

Если без моделирования и глубокого продумывания, то потом переделывать самому боком выйдет.

Если вам платят за глубокое продумывание, то пожалуйста. Просто, имея такой инструмент как Django, дешевле сделать, ошибиться и поправить, чем глубоко продумывать, плодя артефакты в виде UML (боже упаси) и прочие.

PyCraft написал:

Неужели только < 7 и только плоские таблицы без оптимизации? Может это Вы ошиблись?

7 это мало. Даже 30 нормально и 35. Но 70 уже перебор и ошибка в выборе.

В общем суть в том, что  ели вам нравится долго моделировать, или у вас сдельная оплата по количеству UML диаграмм, то пожалуйста.
Вы уже таким подходом породили 9ти ступенчатого монстра, для которого не предусмотрена джанга изначально.

9и ступенчатого монстра я придумал без долгого обдумывания непосредственно во время чтения этого форума.
Долго моделировать мне не то, чтобы нравится. Модель это теория, а построение теории это основное занятие научных работников.
Вот именно за глубокое продумывание технических деталей мне не платят, а жаль.
UML мне тоже не нравится, просто это стандарт, принятый во всем мире. С моей точки зрения, в UML есть фундаментальные ошибки которые являются следствием менталитета его авторов сложившегося под влиянием различных DSL. У меня свой типа "UML" и он в основном не графический, но ложится на интерфейс замечательно.
Что касается моделирования баз данных, то я предпочитаю не UML, а IDEF0, который по сути является DSL для описания схемы базы данных. Надеюсь аббревиатуру DSL вы не ассоциируете исключительно только с Django.

Извините, но по-моему вы развели тут демагогию о том как странно что у строительного пистолета нет 4-кратного коллиматорного прицела, как и почему без без него он Вам не подходит, что там еще Вам не подходит, и как Daevaorn заблуждается в принципах разработки ПО. Не занимайтесь откровенным троллингом.

Почемуже? Мне тут пытаются доказать, что плайнтекст нагляднее IDEF0.
И что лучше и функциональнее плайтекста ничего нет.
Не спорю, холивар голимый - тора vs библией.
Засим прощаюсь.

Отредактированно PyCraft (2008-06-11 15:56:23)

Я встреваю по существу. Вам никто ничего не доказывает, это Вы тут играете в Дон Кихота.

PyCraft написал:

Засим прощаюсь.

Счастливо! Удачи. Как закончите моделировать, возвращайтесь. Может в джанге 4.7 уже добавят редактор и сможете получить из диаграмм модели

lorien написал:

или уже сделали?

Сто лет в обед http://code.djangoproject.com/wiki/DjangoGraphviz

lorien написал:

никакх проектов со ста сущностями не писал

писал и поддерживал.