> Я так понимаю эликсир делали, когда в алхимии ещё не было своей ORM, а сейчас можно из коробки получить функционал ORM
Ну как бы алхимия это и есть ORM… Изначально. Самой первой версии, ещё до первого коммита.
> Выбор за тобой.
Это я опущу. Я соус я не считаю чем-то стандартным, ибо не дорос ещё.
> В чём проблема поднять копию проекта на своей машине?
PostgreSQL, Solr, RabbitMQ, nodejs… И как мне объяснить обычному прграммисту, как весь этот зоопарк у себя собрать и поддерживать? А верстальщики? А обновим чего? Некоторые, блин, хотят дома из винды работать, так там даже fabric по человечески собрать, это уже проблема!
У нас всё централизованно на одной виртуалке с дебианом. Все довольны.
По правде сказать, я не люблю большие команды. Сейчас нас три программиста, два яваскриптизёра-верстальщика, один дизайнер и один айосник. Больше не надо. :-)
В реальном мире, код могут поддерживать не самые высококлассные специалисты и я считаю, что надо думать о том, кто и как после тебя будет работать с этим кодом. И чем меньше магии в нём будет, тем лучше.
Ну да, сносить старые миграции это хорошо и правильно. Но не всегда это хорошо получается. Вот, например, сейчас мы построили большую сложную библиотеку для постоения социальных сетей (ну так, приближённо). В данный момент на ней построенно два проекта и сности миграции очень сложно, так как эти проекты работают с разной версией этих библиотек. Можно, конечно, если заморочиться, но желания ни у кого не возникает.
В что до fabric, то у нас всё куда сложнее. Дело в том, что локально код не крутится и поэтому получается так, что надо отправить последний код на разработческий сервер, создать миграцию и притянуть её в локальное дерево. До сих пор последний момент не до конца автомотизировал…
$ fab rsync.source dj.south.schemamigration:app_name
$ fab deploy.get_path:path/to/app/migrations/XXX_my_mega_migration.py
alembic объективно приятнее в использовании. Пока, конечно, ещё далека от совершентва, но всё равно куда приятнее. Между прочим, либа от создателя самой алхимии.
Кстати, раз уж изучаешь алхимию, могу порекомендовать Elixir. Не знаю, насколько проект жив сегодня, но пару лет назад я с большим удовольствием им пользовался.
> А ты думаешь, если ты руками делаешь изменение схемы базы данных, то это не почва для ошибок?
Ошибиться можно везде, но когда ты вдумчиво описываешь миграцию, вероятность ошибки куда ниже, чем с помощью соуса.
Для очень больших таблиц, понятное дело, надо выдумывать серьёзный велосипед. И, кстати, вот ещё одна проблема: многие ли задумаются о том, что сделал соус и сколько времени оно будет отрабатывать? Как показывает практика, не многие.
Я согласен, что если бы он угадывал переименование, то это было бы ещё хуже. Но, блин, это же такая почва для ошибок, что лучше десять раз подумать, чем вообще вводить в проект такой инструмент.
> Я вообще поля переименовываю так: создаю новое поле, далее отдельной data миграцией переношу данные и затем новой миграцией удаляю старое поле.
Вот это жесть… А вместо mv делаешь cp и rm?
> Я не говорил, что миграции нужны всегда, ты это придумал. Я не говорил, что south надо вводить в джангу, ты это придумал.
Не, ну можно конечно сказать, что это я придумал, но это не очень хорошо выглядет после слов «А что страшного случится, если south добавят в контриб?». Вот вроде бы и придумал, а на деле, просто задродство, уродство и цепляние к словам. И это я не придумал. Надеюсь не встретиться с тобой в реале, удачи!
Изменилось имя поля. Что делает соус? Правильно, удаляет старое и создаёт новое. Чтобы сделать альтертабл руками, надо знать об этой особенности. В моей практике были такие ошибки у средне опытных программистов, ибо это нихрена не очевидно. Слава великой Бжне, до продакшена дело не доходило. И ведь реально, после сдачи проекта в поддержку, там вполне могут оказаться программисты, которые с такой траблой не сталкивались. Впрочем, PEP-20 (Explicit is better than implicit) вообще чужд джанге и большенству её приложений…
Дальше спорить не буду. Если вы не понимаете, что миграции реально нужны не всегда, а введение их в джангу, лишь усложнит её, то и говорить с вами нечего.
P.S. Про качество кода самого соуса я уже высказывался. Мне не раз приходилось его ковырять и это реально ад… Хотя поймут это, наверное, только питонщики, а никак не джангисты.
P.P.S. Свой шаблон можешь распечатать и съесть. Не люблю необоснованую дерзость.
Так, ещё раз, syncdb ничего про миграции не знает. А то, что какая-то библиотечка переопределяет стандартные manage-команды, то это плохой тон и повод оторвать руки разработчикам. Обрати внимание на количество разных мигралок для джанги. Соус не нравится не только мне…
Я знаю вот уже все команды джангистов, котороые осознано отказалась отказались. Лично я считаю, что использовать соус можно только до продакшена. На продакшене безопаснее мигрировать руками.
Да нечего ему там делать. Не самое хорошее приложение с кодом хуже, чем в самой джанге (а это редкость).
В общем, это плохо сочитается с монолитностью джанги, так как syncdb ничего не знает про миграции и знать не должен, ибо они далеко не всегда нужны и часто создают больше проблем, чем пользы.
Ах да, ещё покажу вот это: github.com/utahta/pythonbrew А то в стабильном дебиане до сих пор 2.6…
Виртуаленвы не перечат дебиану, так как собираются у пользователя и не срут в систему. В обшем, нет с ними проблем.
Я не использую MacPorts. Вообще не держу на рабочей машине ничего, что не собирается в виртуальное окружение.
У меня всегда есть сервер (иногда виртуальный — Parallels Desktop) с подходящей ОСью (обычно debian) и набор скриптов на fabric, чтобы одним движением заливать туда нужный код, перезапускать проект и видеть результат.
Это чем virtualenvwrapper является меньшей поделкой, чем virtualenvwrapper?
Вот у меня на сервере Debian Squeeze, который ничего о питоне 2.7 не знает и знать не хочет (про 3.3 даже и говорить нечего). Что делать?
С помощью pythonbrew это решается одним движением. При этом, ничего лишнего, кроме самого pythonbrew (через pip) в систему ставить не надо. Как минимум, это гигиенично, гибко и удобно — раньше я использовал для этого checkinstall и это очень сильно плохое решение.
Плюс создание окружений и переключение между ними работает так же, как и с virtualenvwrapper — одной командой.
В общем, ни одного минуса от его использования я не увидел и и пустил в продакшн.
P.S. virtualenvwrapper прекрасно работает в MacOS X. :-)
Сначала я тоже радовался появлению venv, но теперь, когда есть pythonbrew, я не вижу в нём особого смысла. И virtualenvwrapper, как мне кажется, тоже потерял его.
В общем случае, url это массив байт. Т.е. когда ты делаешь, например, http-запрос, у тебя в нём только байты.
В питоне, конечно же, он представляется массивом символов, что вполне логично и понятно.
Но на самом деле, это всё бред. Думаю, что я не сильно погрешу против истины, если заявлю, что URL, это массив ascii-сиволов. Не ascii в хосте кодируется пуникодом, а в пути — utf-8, представленным в шестнадцатиричном виде с помощью того же ascii. По крайней мере так оно работает в http.
Ну как бы алхимия это и есть ORM… Изначально. Самой первой версии, ещё до первого коммита.
> Выбор за тобой.
Это я опущу. Я соус я не считаю чем-то стандартным, ибо не дорос ещё.
> В чём проблема поднять копию проекта на своей машине?
PostgreSQL, Solr, RabbitMQ, nodejs… И как мне объяснить обычному прграммисту, как весь этот зоопарк у себя собрать и поддерживать? А верстальщики? А обновим чего? Некоторые, блин, хотят дома из винды работать, так там даже fabric по человечески собрать, это уже проблема!
У нас всё централизованно на одной виртуалке с дебианом. Все довольны.
Ну да, сносить старые миграции это хорошо и правильно. Но не всегда это хорошо получается. Вот, например, сейчас мы построили большую сложную библиотеку для постоения социальных сетей (ну так, приближённо). В данный момент на ней построенно два проекта и сности миграции очень сложно, так как эти проекты работают с разной версией этих библиотек. Можно, конечно, если заморочиться, но желания ни у кого не возникает.
В что до fabric, то у нас всё куда сложнее. Дело в том, что локально код не крутится и поэтому получается так, что надо отправить последний код на разработческий сервер, создать миграцию и притянуть её в локальное дерево. До сих пор последний момент не до конца автомотизировал…
$ fab rsync.source dj.south.schemamigration:app_name $ fab deploy.get_path:path/to/app/migrations/XXX_my_mega_migration.pyalembic объективно приятнее в использовании. Пока, конечно, ещё далека от совершентва, но всё равно куда приятнее. Между прочим, либа от создателя самой алхимии.
Кстати, раз уж изучаешь алхимию, могу порекомендовать Elixir. Не знаю, насколько проект жив сегодня, но пару лет назад я с большим удовольствием им пользовался.
Ошибиться можно везде, но когда ты вдумчиво описываешь миграцию, вероятность ошибки куда ниже, чем с помощью соуса.
Для очень больших таблиц, понятное дело, надо выдумывать серьёзный велосипед. И, кстати, вот ещё одна проблема: многие ли задумаются о том, что сделал соус и сколько времени оно будет отрабатывать? Как показывает практика, не многие.
> Я вообще поля переименовываю так: создаю новое поле, далее отдельной data миграцией переношу данные и затем новой миграцией удаляю старое поле.
Вот это жесть… А вместо mv делаешь cp и rm?
> Я не говорил, что миграции нужны всегда, ты это придумал. Я не говорил, что south надо вводить в джангу, ты это придумал.
Не, ну можно конечно сказать, что это я придумал, но это не очень хорошо выглядет после слов «А что страшного случится, если south добавят в контриб?». Вот вроде бы и придумал, а на деле, просто задродство, уродство и цепляние к словам. И это я не придумал. Надеюсь не встретиться с тобой в реале, удачи!
Дальше спорить не буду. Если вы не понимаете, что миграции реально нужны не всегда, а введение их в джангу, лишь усложнит её, то и говорить с вами нечего.
P.S. Про качество кода самого соуса я уже высказывался. Мне не раз приходилось его ковырять и это реально ад… Хотя поймут это, наверное, только питонщики, а никак не джангисты.
P.P.S. Свой шаблон можешь распечатать и съесть. Не люблю необоснованую дерзость.
Я знаю вот уже все команды джангистов, котороые осознано отказалась отказались. Лично я считаю, что использовать соус можно только до продакшена. На продакшене безопаснее мигрировать руками.
В общем, это плохо сочитается с монолитностью джанги, так как syncdb ничего не знает про миграции и знать не должен, ибо они далеко не всегда нужны и часто создают больше проблем, чем пользы.
Виртуаленвы не перечат дебиану, так как собираются у пользователя и не срут в систему. В обшем, нет с ними проблем.
P.S. Намекну: pip freeze
У меня всегда есть сервер (иногда виртуальный — Parallels Desktop) с подходящей ОСью (обычно debian) и набор скриптов на fabric, чтобы одним движением заливать туда нужный код, перезапускать проект и видеть результат.
Вот у меня на сервере Debian Squeeze, который ничего о питоне 2.7 не знает и знать не хочет (про 3.3 даже и говорить нечего). Что делать?
С помощью pythonbrew это решается одним движением. При этом, ничего лишнего, кроме самого pythonbrew (через pip) в систему ставить не надо. Как минимум, это гигиенично, гибко и удобно — раньше я использовал для этого checkinstall и это очень сильно плохое решение.
Плюс создание окружений и переключение между ними работает так же, как и с virtualenvwrapper — одной командой.
В общем, ни одного минуса от его использования я не увидел и и пустил в продакшн.
P.S. virtualenvwrapper прекрасно работает в MacOS X. :-)
В общем случае, url это массив байт. Т.е. когда ты делаешь, например, http-запрос, у тебя в нём только байты.
В питоне, конечно же, он представляется массивом символов, что вполне логично и понятно.
Но на самом деле, это всё бред. Думаю, что я не сильно погрешу против истины, если заявлю, что URL, это массив ascii-сиволов. Не ascii в хосте кодируется пуникодом, а в пути — utf-8, представленным в шестнадцатиричном виде с помощью того же ascii. По крайней мере так оно работает в http.
Андрей Светлов, кажется, писал про возможности расширения этого форматироватья. Пример с датой, это ещё цветочки…