[Moscow.pm] v2 просьба о ревью модуля DBIx::Struct
PEF Secure
pef-secure на yandex.ru
Пт Янв 16 04:40:49 PST 2015
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
Подробная информация о списке рассылки Moscow-pm