Комментарии 16
А слабо почитать документацию и переопределить генератор кода Propel'a свои классом, который будет генерировать эти методы нужным вам образом? В Propel'е для этого все есть.
Propel устанавливается плагинов в Symfony и обновляется непосредственно его разработчиками. Если мне необходимо переопределить генератор кода, то надо изменять плагин. А это значит я меняю код фреймворка.
В документации по Symfony способа обойти эту ситуацию я не нашел. Если знаете, поделитесь ссылкой.
В документации по Symfony способа обойти эту ситуацию я не нашел. Если знаете, поделитесь ссылкой.
При создании проекта у вас должен создаваться файл config/propel.ini. В нем должно быть можно указывать свой класс-генератор.
Точно. Спасибо за информацию. Обязательно попробую. Единственное, что огорчает, что это решение не из коробки (
А оно и не должно быть из коробки. Ссылка может быть как на первичный ключ, так и на колонку с уникальным индексом. Предлагаете все это поддерживать? Мне кажется, что лучше уж дать возможность легко кастомизировать генератор, чем пытаться предусматривать все подряд.
В любом случае вы можете запостить фичу на сайте пропеля: propel.phpdb.org/ :) Кстати, на нем же можно почитать что можно сделать в propel.ini.
В любом случае вы можете запостить фичу на сайте пропеля: propel.phpdb.org/ :) Кстати, на нем же можно почитать что можно сделать в propel.ini.
Спасибо, как раз на днях хотел заняться чем-то похожим. Главное не забывать что при обновлении/создании объекта модели надо обновлять пул (и кэш) или он обновляется автоматически? (в недрах Propel еще не лазил)
P.S. А в сторону Doctrine не смотрели? Там аналогичная ситуация с запросами и кэшированиемили получше?
P.S. А в сторону Doctrine не смотрели? Там аналогичная ситуация с запросами и кэшированиемили получше?
>что при обновлении/создании объекта модели надо обновлять пул (и кэш) или он обновляется автоматически
Обновлять пул не надо, т.к. при вызове метода save обновленный объект кладется в пул автоматически. Необходимо только переопределить 4 указанных в статье метода.
>А в сторону Doctrine не смотрели?
Нет не смотрел. Но там кажется эта ситуация решена.
Обновлять пул не надо, т.к. при вызове метода save обновленный объект кладется в пул автоматически. Необходимо только переопределить 4 указанных в статье метода.
>А в сторону Doctrine не смотрели?
Нет не смотрел. Но там кажется эта ситуация решена.
>Необходимо только переопределить 4 указанных в статье метода.
Спасибо
>Нет не смотрел. Но там кажется эта ситуация решена.
Пожалуй, надо будет с ним поразбираться для нового проекта. При изучении synfony упустил этот аспект, но в последнее время часто слышу, что Doctrine как-то поразумнее сделан, чем Propel.
Спасибо
>Нет не смотрел. Но там кажется эта ситуация решена.
Пожалуй, надо будет с ним поразбираться для нового проекта. При изучении synfony упустил этот аспект, но в последнее время часто слышу, что Doctrine как-то поразумнее сделан, чем Propel.
Сразу предупреждаю, с Propel не работал, и мысли тут будут общего плана.
1. Кеширование — важная проблема, но задачи «есть у нас, например, в выборке 20 фоток – получи 20 запросов в базу, чтобы узнать логин автора фотки» решаются join'ами (+ in-запросами), а никак не кешированием. Propel не умеет делать join'ы? Ну если не умеет, тогда его и правда не стоит использовать.
2. Проблемы с различными open-source инструментами лучше всего обсуждать в баг-трекере соответствующих проектов (если есть конкретные замечания) и в списках рассылки (если не знаешь, как сделать правильно). Если инструмент известный, популярный и хорошо написанный, очень часто выясняется, что человек просто как-то неправильно использует инструмент.
3. ORM — не зло. Из того, что что-то неочевидно в каком-то конкретном ORM не следует, что все ORM-зло. У меня, например, очень положительный впечатления от джанговского ORM (который, правда, не совсем и ORM). По поводу Propel опасения из-за жутковатого синтаксиса есть, это да.
4. А вот патчить исходники библиотек, ломая обновлябельность — действительно зло)
1. Кеширование — важная проблема, но задачи «есть у нас, например, в выборке 20 фоток – получи 20 запросов в базу, чтобы узнать логин автора фотки» решаются join'ами (+ in-запросами), а никак не кешированием. Propel не умеет делать join'ы? Ну если не умеет, тогда его и правда не стоит использовать.
2. Проблемы с различными open-source инструментами лучше всего обсуждать в баг-трекере соответствующих проектов (если есть конкретные замечания) и в списках рассылки (если не знаешь, как сделать правильно). Если инструмент известный, популярный и хорошо написанный, очень часто выясняется, что человек просто как-то неправильно использует инструмент.
3. ORM — не зло. Из того, что что-то неочевидно в каком-то конкретном ORM не следует, что все ORM-зло. У меня, например, очень положительный впечатления от джанговского ORM (который, правда, не совсем и ORM). По поводу Propel опасения из-за жутковатого синтаксиса есть, это да.
4. А вот патчить исходники библиотек, ломая обновлябельность — действительно зло)
1. У меня иное немного мнение на этот счет. Дело в том, что если использовать join'ов в Propel'e продолжая пример указанный в статье на 20 объектов фоток создастся 20 экземпляров объекта юзера, а не один на всех.
2. Согласен, но ведь это скорее рекомендация, а не необходимость )
3. Согласен.
2. Согласен, но ведь это скорее рекомендация, а не необходимость )
3. Согласен.
уже 3 года как нет уникальных экземпляров — уникальность определяется по первичным ключам: propel.phpdb.org/trac/ticket/280
лень разобраться а статью писать не лень?
лень разобраться а статью писать не лень?
Автор не разобрался а туда-же…
методы get...Join… никто не отменял, и не будет 250 запросов, пропел очень хорошо ведет себя со связями — вы сами определяете где что вам нужно
методы get...Join… никто не отменял, и не будет 250 запросов, пропел очень хорошо ведет себя со связями — вы сами определяете где что вам нужно
в Doctrine это решается leftJoin, посмотрите на досуге(:
Про джоины ерунду пишете. Ну да, джоины — нагрузка на базу, но дергать все по pk отдельными запросами — гораздо большая нагрузка на базу.
Вот когда столкнетесь с реальными проблемами с джоинами (запросы с join'ами будут узким местом при правильно расставленных индексах), а не выдуманными (с чьих-то слов «не рекомендуется»), то уже стоит думать дальше — могут помочь in-запросы со списками id, денормализация или какие-нибудь нереляционные СУБД вроде redis или couchdb. Но в 99% не столкнетесь.
Сейчас же Вы просто свалили на ни в чем не повинный Propel все проблемы, вызванные неправильным использованием реляционной СУБД.
Вот когда столкнетесь с реальными проблемами с джоинами (запросы с join'ами будут узким местом при правильно расставленных индексах), а не выдуманными (с чьих-то слов «не рекомендуется»), то уже стоит думать дальше — могут помочь in-запросы со списками id, денормализация или какие-нибудь нереляционные СУБД вроде redis или couchdb. Но в 99% не столкнетесь.
Сейчас же Вы просто свалили на ни в чем не повинный Propel все проблемы, вызванные неправильным использованием реляционной СУБД.
А вот такое решение?
forum.symfony.org.ua/topic/664/svptagedcacheplugin-keshirovanie-s-tegami/
forum.symfony.org.ua/topic/664/svptagedcacheplugin-keshirovanie-s-tegami/
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
ORM – зло или Как я пытался кэшировать Propel в Symfony