(Около)Рабочий дыбр
Oct. 7th, 2010 10:09 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
beldmitВо первЫх строках сообщаю, что на новой работе хорошо. Минусы - ехать туда минут на 10 дольше, чем на старую. Плюсы - что это все в более жилом районе, и с инфраструктурой там, как в жилом районе, а не в промзоне. То есть и магазины, и рыночек, и аптеки, и, небось, сбербанк где-то есть. И идти вечером до метро приятно. И доставка обедов в офис.
Новые знакомства пока не заводятся. Впрочем, старых для работы хватает,а так как сижу в кабинете, где всего 3 человека, один из которых еще не вышел, то с новыми знакомствами придется, видимо, повременить.
Далее - программистское.
Оказывается, примитивный ORM сотворяется на SQL::Abstract за пару часов. Самое интересное, что потом он еще и работает.
Еще оказывается, что со всякими нестандартными постгресовыми типами работать через plain SQL существенно удобнее. То есть
1. Работу с BITSTRING я так и не осилил.
2. для HSTORE гуглится сериализатор.
3. С массивами SQL::Abstract работает из коробки - но не удалось завернуть соответствующую постгресовую конструкцию: элемент, проверяемый на наличие в массиве, должен быть слева, т.е. условие ? = ANY(array) работает, но сходу не пишется, а наоборот - пишется, но не работает.
4. ENUM работает как родной, но добавить в него значение в PostgreSQL до 9.0.1 - фиг, надо явно создавать новый тип.
Да, я в курсе, что есть DBIx::Class. Но сборщики RPM-ов - скорее не в курсе. И вообще оказывается, что на CentOS перловые модули - древние как не знаю что. Правда, пока это не критично.
Да, если кто-то хочет попрограммировать на Perl - welcome. Платят аккуратно, задачи есть, перспектива есть. Но прямо сейчас - только на подряд.
Новые знакомства пока не заводятся. Впрочем, старых для работы хватает,а так как сижу в кабинете, где всего 3 человека, один из которых еще не вышел, то с новыми знакомствами придется, видимо, повременить.
Далее - программистское.
Оказывается, примитивный ORM сотворяется на SQL::Abstract за пару часов. Самое интересное, что потом он еще и работает.
Еще оказывается, что со всякими нестандартными постгресовыми типами работать через plain SQL существенно удобнее. То есть
1. Работу с BITSTRING я так и не осилил.
2. для HSTORE гуглится сериализатор.
3. С массивами SQL::Abstract работает из коробки - но не удалось завернуть соответствующую постгресовую конструкцию: элемент, проверяемый на наличие в массиве, должен быть слева, т.е. условие ? = ANY(array) работает, но сходу не пишется, а наоборот - пишется, но не работает.
4. ENUM работает как родной, но добавить в него значение в PostgreSQL до 9.0.1 - фиг, надо явно создавать новый тип.
Да, я в курсе, что есть DBIx::Class. Но сборщики RPM-ов - скорее не в курсе. И вообще оказывается, что на CentOS перловые модули - древние как не знаю что. Правда, пока это не критично.
Да, если кто-то хочет попрограммировать на Perl - welcome. Платят аккуратно, задачи есть, перспектива есть. Но прямо сейчас - только на подряд.
