[Uneex] К вопросу об организации разработки под Zope2
Andrey Orlov
cray_uneex на neural.ru
Пт Дек 8 18:13:49 MSK 2006
On Friday 08 December 2006 16:38, Max Lapshin wrote:
> > Кроме того,
> > я про количество объектов ничего не говорил, я говорил только про
> > роль в
> > приложении.
>
> Спасибо, я услышал вас.
Не услышали :), так же как и всех, с кем консультировались до меня. Так как я
уверен - каждый расказал бы вам нижеследующее.
Ну так вот. Еще раз - ZODB играет в Zope ту же роль, что и другие базы данных
в других приложениях. Например, MySQL в Midgard. Причем, Midgard шаблоны тоже
хранит в MySQL :). Относитесь к ZODB просто как к базе данных:
сооответственно, если уж начинаете работать на уровне базы, работайте с
репликами :) или с дампами.
Теперь о коллективной разработке под Zope2 c использованием SVN. Такого
опыта у мя не было, но только по тому, что мы использолвали CVS. Проблема
решается аж несколькими путями:
1. Для Zope2 существовал прродукт, позволяющий брать содержимое папки
в Zope2 из CVS и сохранять его обратно. С мержами и т.д.т.п., насколько я
помню. Названия - увы - не вспомню, но такой продукт был и по крайней мере в
Zope 2.5.1 работал (я тогда был одним из редакторов книги, в которой он
описывался, и тщательно его протестировал). Правда, должен сказать,
мне идея не очень понравилась - почему расскажу ниже.
2. Для Zope2 существовал продукт, позволяющдий хранить темплейты (равно как и
любое другое содержимое) на диске. LocalDirectory он назывался или типа
того :), знавал я одну компанию, которая при __разработке__ использовала его,
сохраняя ту самую Directory в CVS. Насколько им это было удобно - не
расскажу, было это очень давно.
3. Наконец, никто не мешает __просто__ хранить темплейты в продуктах для Zope,
а не в базе данных. Прописав в этом продукте процедуру либо установки в Zope
(такое часто используется для СКИНОВ), либо процедуру доступа (стандартными
средствами Zope регистрируются для доступа). Я такие способы не люблю %), но
вот для скинов его использовал. Опять же, все исходные коды (темплейты)
хранились в SVN.
4. Можно попробовать смонтировать ZODB как файловую систему davfs. Я такого
не пробовал, и о таком не слышал :), но davfs или что-то типа того реально
существует :). По крмре, существовала.
5. Ну и самый последний способ. Описан, кстати, в руководстве для CVS как
рекомендуемый для таких проектов. Как известно, в zope2 можно заливать
темплейты (да и что угодно) достаточно простым способом: ftp, webdav, да
собственно и http. Способ такой: хранить темплейты в CVS, редактировать их
тоже там, по факту коммита поставить в CVS триггер который по факту коммита
будет аплоадить данные в zope. Опять же, каждый может пользоваться своим zope
и сливать оттуда темплейты. Кажется немного гемморным, но на самом деле пять
скриптов на шелле - и все ОК. Мы так работали года два, без каких либо
проблем.
На самом деле, решений можно придумать очень много. И даже если уж и сохранять
что-то "типа zodb" в CVS - то сохраняйте реплики: zexp или xml. XML можно
мержить (существует продукт про то, что бы мержить xml), хотя это уже близко
к извращению, из-за особенностей zodb-шного xml, хотя это решаемо. Есть же
скрипт по перекодирования ZOPE сайта, сохранненного в виде xml-реплики :).
Теперь про остальные ваши вопросы:
>> Вопрос второй такой: рестарт Zope — фантастически длинное время.
Только если база не была корректно закрыта и требуется перестройка индекса.
Некоторые версии Zope2 не умеют корректно закрывать базу. Хотя да, zope
стартует долго, он так устроен. Зато быстро отвечает на запросы.
>> Только рестартить его надо по каждому изменению каждой строчки кода.
Пожалуйста, почитайте RTFM про отладочный режим и авторефрешь. Это реально
работает, такие изменения в дисковых продуктах, которые требуют __рестарта__
при интенсивной разработке бывают раз в день (по нашему опыту) и обычно
свидетельствуют о том, что что-то где-то сделано очень грязно. Либо вами,
либо авторами смежных продуктов.
Напоследок: все вышесказанное вам поможет если вы, вообще говоря,
придерживаетесь "правильной" архитектуры при разработке zope приложений.
Если архитектура такая же правильная, как идея хранить данные в ZODB - ну, вам
это не поможет. Тут уже чтото в консерватории надо что-то менять ;)
Теперь про Zope3:
Он по прежнему основан на ZODB, ...... впрочем, это лучше отдельным письмом,
и отдельным тредом. Наверно интересно не только вам.
PS: Кстати, вы не захотели слушать Михаила Кашкина, а у него очень большой
опыт коллективной разработки под Zope2, значительно больше моего.
И, хотя мы с вами такие способы отвергаем, я повторю его слова: "Необходимость
мержей сильно преувеличена", - попробуйте послушать то, что он вам расскажет.
До сих пор, я так понимаю, вы вместо того, что бы спросить "как организовать
коллективную разработку в zope" спрашивали "как хранить data.fs в SVN", после
чего zope-авторитеты падали в обморок :), на вопросы типа "зачем" вы не
отвечали, а писали им что-то типа "спасибо, я вас услышал" или обвиняли в
даче заведомо ложной информации, приписывая им те слова, которые они не
говорили.
Не самый лучший вариант поведения с вашей стороны :). Хотя конечно, смотря по
тому, чего хотелось достичь.
--
---
WthBstRgrds --
-- Andrey Orlov
--- + 7 926 222 99 63 -----
Подробная информация о списке рассылки Uneex