переход в спящий режим, возможно смешивать нагрузку с критериями?

#hibernate #generics

#переход в спящий режим #дженерики

Вопрос:

возможно ли смешивать session.load(class, id) с гибкими критериями (criterions api)?

Мне нужно что-то вроде :

 select * from entity where id = 1 AND name = 'miller'
  

Я использую общий подход для поиска по id :

 public T findById(ID id, boolean lock) {
    T entity;
    if (lock)
        entity = (T) getSession().load(getPersistentClass(), id, LockMode.UPGRADE);
    else
        entity = (T) getSession().load(getPersistentClass(), id);

    return entity;
}
  

и хотел бы расширить это за счет

     Criteria criteria = session.createCriteria(getPersistentClass());
    criteria.add( Restrictions.eq("name", "miller"));
  

where ("name", "miller") будет заменено чем-то общим.

Ответ №1:

Загрузка и критерии не могут быть смешаны. Загрузка создает прокси, если экземпляр еще не находится в кэше. Цель load (и get) заключается в том, что его аргументы являются ключами для кэша (class и id), и ему не нужно предварительно очищать сеанс. Критерии — это своего рода запрос. Когда вы уже знаете идентификатор, вам больше не нужен запрос. Я имею в виду, id = 1 AND name = 'miller' имеет ли какой-либо смысл?


Просто напишите свое собственное «Get»:

 public TEntity secureGet<TEntity>(int id, string user)
{
  // avoid flushing, only when you never expect that the user name
  // in the object to be loaded has changed within the current session.
  // this is very performance relevant.
  session.flushMode = FlushMode.Never;
  return session
    .createCriteria(typeof(TEntity))
    .add( Restrictions.idEq(id))
    .add( Restrictions.eq("name", user))
    .UniqueResult<TEntity>();
  session.flushMode = FlushMode.Auto;
}
  

(Извините за возможные синтаксические ошибки, я не Java-программист)

Комментарии:

1. Да, это имеет смысл как часть концепции авторизации. Я мог бы проверить, разрешено ли текущему пользователю просматривать данные с id = 1.

2. @dodiddone: каков ваш план для достижения этого? Разве вам не нужна другая таблица с пользовательскими разрешениями в отношении конкретных записей из класса Entity?

3. добавлен пример реализации.

4. @Olaf да, это правильно, я упростил пример, я добавил объекты с пользовательскими разрешениями и т.д.