[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