[Moscow.pm] v2 просьба о ревью модуля DBIx::Struct

[PEF Secure]

On Thursday, January 15, 2015 19:19:25 Warstone на list.ru wrote:
>  То есть сложных проектов, где есть "Ядро" и "Приложение", или гетерогенных,
> сервис-ориентированных приложений вы не писали? Хорошо... Вот вам пример из
> жизни...

Придумывание чужих профилей самостоятельно -- это такое завуалированное 
оскорбление? 

> Есть Ядро, в ядре есть определение пользователя. Таблицы пользователя. Как
> будет использоваться пользователь и какие у него будут дополнительные поля
> определяется приложением.  Ядро заботится о "стандартных" полях. У
> пользователя есть аватар. В модели есть аксессор для урла на аватар. Ядро,
> зная что серверов много и выбирая какие сервера сейчас активны, на каких из
> них есть этот аватар и т.д. отдает Урл аватара. Для Приложения это просто
> аксессор.

Мне не удаётся увидеть в этом проблему, связанную с обсуждаемым модулем. Речь 
идёт о доступе к базе данных. Какие поля есть у пользователя -- определяется 
динамически в момент коннекта к базе или вызовом метода populate(), который 
заново может перечитать структуру базы.

> То что я описал - это один из примеров. Возможно не самый лучший. Но он дает
> представление о том, что ждут большие приложения от ORM'а. Если вы сможете
> поддержать ORM, когда я, написав сложный SQL запрос с аггрегатами и
> оконными процедурами в результате получив пользователя , получу урл на
> аватар, прогнанный через мой аксессор, не указывая что это пользователь (то
> есть ORM сам должен понять - откуда это взялось и что надо сделать с
> полями), то можно начинать разговаривать про ваш ORM.

В моём представлении, тут уже есть некоторая смесь понятий ORM и логики ядра. 
Ядро спросили URL, оно ответило. Откуда оно его взяло, какими модулями 
пользовалось -- совсем не важно. Для ядра у меня есть другой фреймворк, в 
котором _возможно_ использовать DBIx::Struct, он (другой фреймворк) не готов к 
публичному релизу и я его пока не намереваюсь обсуждать. 

В самом первом сообщении я сразу определил, что модуль не пытается строить из 
себя настоящую ORM, но обладает её некоторыми чертами. Все "сложные" случаи 
оставлены "настоящему" SQL, который, на мой взгляд, куда понятнее и проще 
поддаётся отладке.

> До этих пор большого
> смысла использовать его в "продакшене" я не вижу. Проблема в том, что я
> плохо представляю как этого добиться, не указывая очень много
> дополнительной информации при каждом запросе. Хотя вру... Для PostgreSQL -
> знаю как. Но только для него.

Я не знаю что у Вас там за приложение, но, видимо, что-то мега-крутое. В своих 
проектах последние 5 лет стараюсь использовать только PostgreSQL, чему и рад, 
столкновения с MySQL часто вызывают у меня недоумение. Например, рекурсивный 
запрос для построения дерева комментариев к статье.

> Согласен. Хотя у нас используются сразу 2 СУБД: PostgreSQL и MySQL. Такой
> вариант немного сбивает с толку, правда?

Правда. Никто не застрахован от "странных" случаев. Мне приходилось работать 
одновременно с PostgreSQL и MySQL, но вторая база только для "специальных" 
случаев, там можно просто DBIx::Connector как есть использовать.

> Это не следует из вышенаписанного по причинам, изложенным выше.

Это моя точка зрения. Если база известна, то "диалект" SQL уже не является 
препятствием. Проблема, когда пишется что-то обобщённое, что должно учитывать 
возможные диалекты.

> Для этого и существуют ORM. ORM (Object Relationship Mapping) и есть эта
> абстракция и именно об абстракции мы и говорим.

Целей у неё, как я понимаю, две: концептуально не использовать SQL, перейдя на 
"родные" структуры языка; абстрагироваться от БД, что может дать некоторую 
свободу приложению, а может и наоборот, внести ограничения.

> SQL::Abstract для этого и придумали. Не только для этого, конечно. Они не
> мыслили так узко.

Ну ясно дело, узко -- это мой удел, я понял.

> Вы на этапе архитектуры подписались на то, что у вас не будет высокой
> нагрузки, так как иначе будет боттлек в базе. И чем больше логики вы будете
> класть в базу (а вы будете это делать, по причинам вышеописанным) тем вам
> будет потом больнее это переделывать.

Чем больше нагрузка на базу, тем сильнее надо думать о кешировании данных. Это 
выходит за рамки модуля. Хранимые процедуры, наоборот, за счёт более близкого 
доступа к данным дают выше пропускную способность базы, с тригерами тоже надо 
быть аккуратными, но в правильных случаях они не мешают и помогают сохранить 
логическую стркутуру базы.

Вобщем, про боттлнек в базе _тут_ не понял.

> Вы между первым и 2м выбрали первое. Вам не нужен ORM вообще. 

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

$row = $dbh->selectrow_hashref('select * from user where login = ? and 
password = ?', undef, $login, $password) 

за много лет задолбало. В итоге оно постепенно вылилось в то, что при коннекте 
получается структура таблиц, между ними строятся связи, по этим связям можно 
создавать упрощённые запросы:

$row = one_row([article => -join => 'author'],{id_article => $id_article}) 

в объекте $row будет разбирая на поля выборка 

select * from article join author on (article.id_author = author.id) where 
id_article = ?

Получилось у меня привести это к чисто перловым структурам данных? Мне 
кажется, вполне. 

Абстрагировался ли я от конкретной БД? Ну почти, реальные тесты делал только 
на PostgreSQL, предусмотрел пару моментов по майскл и склайт, но их не 
тестировал за неимением. 

Стало ли это выглядеть лучше, чем было? Ну мне так больше нравится. 

> И приложение не проектируется под большую нагрузку. 

Максимально допустимая нагрузка определяется множеством факторов. Как по мне, 
модуль DBIx::Struct вряд ли будет тормозом. Даже скорее наоборот, расход 
памяти для хранения данных ниже, чем когда строка результата выборки 
представлена хешем. Грубое тестирование не выявило разницы с чистым DBI.

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

Имею иное мнение :)
-- 
PEF Developer