Начал изучать эту ORM, и она мне показалось очень вкусной. Но вот возник вопрос: можно ли как-то с помощью Propel реализовать механизм глобальных фильтров. Поясню на примере.
Допустим, я делаю некий SaaS. У меня есть с десяток моделей, у каждой из которых есть поле company_id, очевидно, показывающее принадлежность к компании. Таким образом мне в каждом запросе необходимо писать дополнительное условие filterByCompanyId($id), так же в каждом INSERT надо подставлять отдельно ID компании.
Было бы очень круто, если можно было бы 1 раз где-нибудь в базовом контроллере прописать условие, что-то типа $propel->globalFilterByCompanyId($id), затем это условие автоматически добавляется в каждый запрос для моделей, которые содержат поле company_id (причем не только в запросы типа SELECT, но и DELETE, UPDATE, INSERT).
Это хорошо не только для сокращения количества кода, но и для улучшения декомпозиции логики: мы прописали условие на компанию, затем полностью абстрагируемся от конкретной компании и пишем всю дальнейшую логику так, как будто бы делаем сайт для одной компании.
Если Propel такое не умеет, было бы интересно узнать, умеют ли такое другие ORM, потому как я не встречал такого нигде.
Можно немного по-другому переопределить проблему. В Propele есть методы Query preSelect(), preUpdate(), preDelete() и т.д. Проблему можно было бы легко решить, если возможно было переопределять эти методы динамически в коде. Но, насколько я понял из документации, эти методы жестко прописываются в классе. Дальше их нельзя изменить
Не знаю на счет Propel.
Я обычно использую Doctrine и там есть Repository и ObjectManager
В них с помощью наследования нетрудно переопределить стандартные методы, и дописать в них необходимые условия.
Аналог Repository есть в Propele, но документированных возможностей не хватает, чтобы провернуть такую операцию. Про ObjectManager и что он умеет я почитаю, но вообще с Doctrine я работал, и как-то не вдохновило
Подобного метода, насколько мне известно, в Propel нет. И, как мне кажется, вот почему. То, о чем Вы говорите, это не совсем уровень ORM, это уже бизнес-логика и разработчики просто не могут предсказать все варианты использования своего инструмента.
Да и в конце-концов, Вы можете просто настроить связи в модели Company и делать выборку по связанным полям(с dml уже не так просто будет)
Почему же не совсем уровень ORM? Можно же с помощью preSelect() задать какие угодно дефолтные условия выборки. Но с preSelect() можно задать условия только с заранее известными параметрами. То, что я спрашиваю, это тот же preSelect() только с возможностью его динамически изменять в коде. Вполне себе уровень ORM. Очень жалко, что такие фичи не встраивают в ORM.
Дело в том, что ORM должен отвечать за проекцию реляционной модели на ОО-модель и все(в идеале, конечно). Те же pre-методы, это всего лишь обработчики событий, которые задаются в классе запроса. Их применение может быть гораздо шире, чем модификация запросов.
В принципе, если Вам нужно сделать так, чтобы была возможность из клиентского кода устанавливать обработчики этих событий, то советую посмотреть в сторону шаблона Наблюдатель
Вот простейший пример(для нормальной работы потребуется его допилить): pastebin.com/evTViJyH
Средний