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

[PEF Secure]

On Friday, January 16, 2015 14:45:17 Warstone на list.ru wrote:
>  Я, наверно, последний раз напишу, так как далее бессмысленно, очевидно...

Поскольку ж написали, мне придётся ответить :)

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

Ну сгенерируется и скомпилируется код на каждый _класс_. Он и так и этак бы 
компилировался, что при ORM, что с моим модулем. Речь может идти только о 
"производных" классах, которые основаны на генерящихся запросах, тут всё от 
приложения зависит, но мне сомнительно, что это такая уж проблема.

> >Хотя ладно, это придирка. Могу еще одну
> >рассказать... Вы пользуете DBIx::Connector, который в себе при создании
> >имеет следующее: $self->{pid} = $$; Прощай форк после вашего populate'а.

Почему же? Стартап: connect, populate. Дальше форки могут идти сколько угодно, 
их кухню от меня скроет DBIx::Connector. Если речь о prepared, то их 
использования пока нет, и "прозрачный реконнект" как одна из причин. Хотя уже 
давно думаю над их внедрением. 

> >Прощай здравый смысл. Хотя это не ваша вина, но анализировать модули,
> >которые используете - имеет смысл.

Анализировал. Если посмотреть на мой DBIx::Struct::Connector, то можно понять, 
что внутрь коннектора я смотрел. Кстати, туда возможно и встрою кеширование и 
сброс prepared.

> Сделать "просто". Если мне не допустим надо сделать аудит в моем
> >варианте я перебиваю базовые методы в Base пакете. В вашем мне надо по
> >всей схеме пройтись. Это для примера.

Слишком абстрактно. Но идею я понял. Как вариант, могу сделать настройку, 
чтобы все генерируемые классы наследовали какой-то, который будет указан. Если 
я правильно понял вопрос.

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

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

> Я лучше подготовлюсь путем неиспользования
> модуля, особенно если у него есть альтернативы 

Насильно мил не буду.

> (DBIx::Simple + SQL::Abstract, у которых так-же есть проблемы с форками,
> кстати).

Смотря что называть проблемами. Вот я привёл пример демо-приложения. Там PSGI. 
Приложение запускается, в стартапе происходит connect(), populate(), затем уже 
запущенное и проинициализированное приложение передаётся в uwsgi для форков по 
мере надобности. 

> Ну куда вы полезли?.. Доступ к хешу в классе. Вы экономите чуть-чуть на
> кждом созданном классе таким образом, а не объекте.

Зависит от меры "чуть-чуть". В два раза минимум, ведь как минимум массиву не 
нужно хранить названия ключей для каждой строки, их знание обозначено один раз 
в описании класса. Экономлю именно на каждом созданном объекте. Убедиться в 
разнице memory footprint можно используя модуль Devel::Size.

> >А для вас динамический - это только eval? 

Нет, но именно при написании _фреймворка_ мне это видится очень полезным 
свойством. До написания фреймворка пользовался им для перехвата исключений, в 
основном.

> Вопрос не почему вы это сделали, а почему вы это сделали не
> >везде. Но тут возможно просто не нашли все, так как текст, а не код...

Спасибо за багрепорт, поищу где пропустил.

> Проблема вот в этом: setup_row('table1',
> >'MySchema::Table'); setup_row('table2', 'MySchema::Table'). На 2-м должен
> >упасть. У вас не падает.

Там иной сценарий использования. Это внутренний метод, такого варианта, что Вы 
написали, в модуле нет. 
-- 
PEF Developer