Фильтровать CayenneDataObject getXXXArray () записей с параметрами? - PullRequest
Новая
       24

Фильтровать CayenneDataObject getXXXArray () записей с параметрами?

1 голос
/ 23 ноября 2010

Моя модель БД выглядит следующим образом: 

A.id (1 : n) B.ad_id

Таким образом, в cayenne для объекта A a я могу сделать a.getBArray(), который возвращает мне все записи из B из данной записи A.Тем не менее, я хотел бы отфильтровать этот список, основываясь на свойстве active = 1.

. Очевидно, я могу использовать Expression.fromString("active = 1") с SelectQuery, но для этого подхода я не могу найти, как связать Aэкземпляр, под которым я хочу выполнить этот запрос.

Другой подход заключается в извлечении всех записей из a.getBArray() и фильтрации в коде для поиска только тех, которые имеют active == true, этот подход, IMHO, неэффективен.

Рекомендации в основном приветствуются.*

Спасибо, Максим.

- РЕДАКТИРОВАТЬ:

Мое текущее решение: (имена объектов были заменены на a & b соответственно): 

long aId = DataObjectUtils.longPKForObject(db_a_instance);
String bSQL = "select * from b where active = 1 and a_id = " + aId;
SQLTemplate bQuery = new SQLTemplate(B.class, bSQL);
List<B> dbBs = context.performQuery(bQuery);

и я спрашиваю, есть ли лучшее, более элегантное решение?

Спасибо.

1 Ответ

2 голосов
/ 24 января 2011

Я задал похожий вопрос в списке дружественных рассылок Кайенны. Вы можете увидеть здесь .

Казалось, что предпочтительным подходом является использование отношений и фильтрации в Java, если отношения не возвращают очень большие данные. Преимущество этого состоит в том, что полный список будет в памяти, и в следующий раз, когда вы используете отношения, вам не нужно совершать поездки в БД.

Ответ приводится здесь

Оба требуют поездки в БД.

  1. (подход обхода в отношениях) требует однократного отключения к БД для сбоя групп из БД, но тогда это будет в памяти.

  2. (запрос с подходом фильтра) требует отключения в БД каждый раз, что может быть медленнее в долгосрочной перспективе, даже если оно возвращает меньше совпадений.

Если это то, что происходит только один раз, и вы ДЕЙСТВИТЕЛЬНО обеспокоен производительностью (и, возможно, иметь много групп), я бы перейти с № 2, в противном случае № 1. Вы тоже можете немного оптимизировать # 1, так что вы не нужно повторять каждый раз для проверки.

через: Майкла Джентри

...