Feb 02

Столкнулся я вот тут с ситуацией и хочу попросить помощи у читателей.

Имеется:

Таблица в базе данных, содержащая некоторые записи. У записей есть “переключатель” - одобрена/неодобрена (для тех, кто в танке - булевое поле approved). Для этой таблицы (и всех остальных таблиц в бд) есть ORM.

Нужно:

Обеспечить для большей части частей системы удобный доступ только к записям с approved = true, при этом нужно учесть, что другие таблицы также могут быть связаны с данной и в ORM’е есть метода доступа к записям в данной таблице. Грубо говоря имеем нечто типа такого:

Table ProductType
Table Product
$someProductType->fetchAllProducts()
Product::fetchAll()

То есть, доступ к данной таблице есть во многих местах и все такие места менять ОЧЕНЬ не хотелось бы.

Но это половина проблемы, и в моем случае не самая страшная т.к. у таблицы есть ОДИН метод, к которому обращаются все остальные (пусть это будет Product::fetchByParameters()), и заменив только его я получу то, что мне нужно.

Главная проблема в том, что мне еще нужно в некоторых местах доступаться ко всем записям, даже неодобренным. Таким образом, способ приведенный выше отпадает. Каким образом можно подобную функциональность поиметь - я не представляю. Кто-нибудь может помочь?

written by fxposter \\ tags:

One Ping to ““approved” and “unapproved” records”

  1. “approved” and “unapproved” records: решение » Блог FX'а Says:

    […] “всё гениальное – просто”. И решение моей проблемы оказалось до ужаса простым, причем думать даже не […]


10 Responses to ““approved” and “unapproved” records”

  1. 1. DM Says:

    public function fetchAll($include_unapproved=false) {

    //where condition
    if(!$include_unapproved) {
    $sql=$sql.’ AND approved=1 ‘;
    }

    }
    ?

  2. 2. zhulanov Says:

    согласен с DM’ом. Не очень понятно в чем проблема на самом деле =)

  3. 3. Steward Says:

    ну или можно добавить свойство include_unapproved в класс и перед вызовом метода его инициализировать. А в самом методе проверять – но так как было показано выше – практически идеально – и код не придётся вообще менять.. только там где нужны все записи – вставить в вызов функции true

  4. 4. FX Poster Says:

    Кажется я непонятно изьясняюсь. :)

    Есть КУЧА функций и 3 или 4 класса ORM’а, которые непосредственно связаны с данной таблицей. Сгенерированные автоматически (да, да, это Propel). В них набежит порядка 15-20 функций, которые такили иначе связанны с данной таблицей. Мне во все эти функции вставлять дополнительный параметр? А если еще классы появятся? Снова вставлять?

    Предложенный вариант аналогичен (более-менее) тому, что я всё оставляю как есть, а где использую эту таблицу – внимательно проверяю, нужны ли мне только approved-записи и если да – добавляю нужный критерий для выборки. Т.е. изменяю код в контроллерах, не трогая модели.

    Два варианта равнозначны и… проблему вы, я надеюсь, узрели. :)

    Т.е. хочется увидеть удачное решение такой проблемы. Или хотя бы слова о том, что его не существует. :)

  5. 5. Анатолий Фролов Says:

    по-моему ответ DM вполне подходит

  6. 6. FX Poster Says:

    Ок. Мне вот такие кондишены добавлять в двадцать функций?

  7. 7. DM Says:

    К сожалению, похоже что во все 15 добавлять. Привет rails с плагином scope_out.

  8. 8. Steward Says:

    эм… а если создать view – по два на каждую таблицу – это не спасёт отца русской демократии?

  9. 9. FX Poster Says:

    Ты о чем вообще?

  10. 10. Steward Says:

    “Есть КУЧА функций и 3 или 4 класса ORM’а, которые непосредственно связаны с данной таблицей” – нельзя ли вместо таблицы использовать view?
    Оба view имеют ту же структуру что и таблица – только один построен с условие что запись “approved”, а второй – “unapproved”…

    хотя наверное в данном слчае придётся ещё больше переписывать :(

Leave a Reply