Столкнулся я вот тут с ситуацией и хочу попросить помощи у читателей.
Имеется:
Таблица в базе данных, содержащая некоторые записи. У записей есть “переключатель” - одобрена/неодобрена (для тех, кто в танке - булевое поле approved). Для этой таблицы (и всех остальных таблиц в бд) есть ORM.
Нужно:
Обеспечить для большей части частей системы удобный доступ только к записям с approved = true, при этом нужно учесть, что другие таблицы также могут быть связаны с данной и в ORM’е есть метода доступа к записям в данной таблице. Грубо говоря имеем нечто типа такого:
Table ProductType
Table Product
$someProductType->fetchAllProducts()
Product::fetchAll()То есть, доступ к данной таблице есть во многих местах и все такие места менять ОЧЕНЬ не хотелось бы.
Но это половина проблемы, и в моем случае не самая страшная т.к. у таблицы есть ОДИН метод, к которому обращаются все остальные (пусть это будет Product::fetchByParameters()), и заменив только его я получу то, что мне нужно.
Главная проблема в том, что мне еще нужно в некоторых местах доступаться ко всем записям, даже неодобренным. Таким образом, способ приведенный выше отпадает. Каким образом можно подобную функциональность поиметь - я не представляю. Кто-нибудь может помочь?
One Ping to ““approved” and “unapproved” records”
10 Responses to ““approved” and “unapproved” records”
-
1. DM Says:
February 2nd, 2008 at 03:22public function fetchAll($include_unapproved=false) {
…
//where condition
if(!$include_unapproved) {
$sql=$sql.’ AND approved=1 ‘;
}
…
}
? -
2. zhulanov Says:
February 2nd, 2008 at 10:37согласен с DM’ом. Не очень понятно в чем проблема на самом деле =)
-
3. Steward Says:
February 2nd, 2008 at 11:24ну или можно добавить свойство include_unapproved в класс и перед вызовом метода его инициализировать. А в самом методе проверять – но так как было показано выше – практически идеально – и код не придётся вообще менять.. только там где нужны все записи – вставить в вызов функции true
-
4. FX Poster Says:
February 2nd, 2008 at 11:50Кажется я непонятно изьясняюсь. :)
Есть КУЧА функций и 3 или 4 класса ORM’а, которые непосредственно связаны с данной таблицей. Сгенерированные автоматически (да, да, это Propel). В них набежит порядка 15-20 функций, которые такили иначе связанны с данной таблицей. Мне во все эти функции вставлять дополнительный параметр? А если еще классы появятся? Снова вставлять?
Предложенный вариант аналогичен (более-менее) тому, что я всё оставляю как есть, а где использую эту таблицу – внимательно проверяю, нужны ли мне только approved-записи и если да – добавляю нужный критерий для выборки. Т.е. изменяю код в контроллерах, не трогая модели.
Два варианта равнозначны и… проблему вы, я надеюсь, узрели. :)
Т.е. хочется увидеть удачное решение такой проблемы. Или хотя бы слова о том, что его не существует. :)
-
5. Анатолий Фролов Says:
February 4th, 2008 at 13:40по-моему ответ DM вполне подходит
-
6. FX Poster Says:
February 4th, 2008 at 18:08Ок. Мне вот такие кондишены добавлять в двадцать функций?
-
7. DM Says:
February 4th, 2008 at 18:32К сожалению, похоже что во все 15 добавлять. Привет rails с плагином scope_out.
-
8. Steward Says:
February 4th, 2008 at 22:12эм… а если создать view – по два на каждую таблицу – это не спасёт отца русской демократии?
-
9. FX Poster Says:
February 4th, 2008 at 23:33Ты о чем вообще?
-
10. Steward Says:
February 4th, 2008 at 23:49“Есть КУЧА функций и 3 или 4 класса ORM’а, которые непосредственно связаны с данной таблицей” – нельзя ли вместо таблицы использовать view?
Оба view имеют ту же структуру что и таблица – только один построен с условие что запись “approved”, а второй – “unapproved”…хотя наверное в данном слчае придётся ещё больше переписывать :(
February 9th, 2008 at 14:14
[...] “всё гениальное – просто”. И решение моей проблемы оказалось до ужаса простым, причем думать даже не [...]