Возвращает ли Hibernate нулевую или пустую коллекцию, если таблица в отношении пуста?

Мне было интересно что-то. Скажем, у нас есть простая связь между Employee и Phone:

@Entity
public class Employee {
  @Id
  @Column(name="EMP_ID")
  private long id;
  ...
  @OneToMany(mappedBy="owner")
  private List<Phone> phones;
  ...
}
@Entity
public class Phone {
  @Id
  private long id;
  ...
  @ManyToOne(fetch=FetchType.LAZY)
  @JoinColumn(name="OWNER_ID")
  private Employee owner;
  ...
}

Предположим, что у Работника нет телефонов, нет записей в телефонной таблице. Если бы у меня был кусок кода, который получает телефоны сотрудника и итерации по ним по какой-либо причине

for (Phone phone : employee.getPhones())
{
     ...
}

Будет ли геттер переназначать NULL или пустую коллекцию и будет ли стратегия рисования играть роль.

Если я правильно помню, у hibernate есть своя реализация коллекции с использованием прокси и для LAZY fetch, она создает экземпляр с одним из них и, когда необходимо, извлекает данные из таблицы (правильно, если я ошибаюсь). Таким образом, в то время, когда будет вызван приемник, попробуйте извлечь данные из таблицы, получить пустой набор в качестве результата и вернуть пустую коллекцию. (Это то, что я думаю). Или я должен всегда проверять, является ли результат getter равным NULL или нет?

Ответы

Ответ 1

Поскольку эти коллекции полны по умолчанию, employee.getPhones() должен возвращать прокси для этой коллекции (например, PersistentList или аналогичный), который загружает элементы списка при доступе к списку.

Кроме того, поскольку Phone является владельцем отношения, Hibernate не будет знать, существуют ли какие-либо телефоны для сотрудника или нет, поэтому он должен предположить, что список существует, хотя он может быть пустым. Тем не менее, Hibernate не имеет смысла возвращать null, поскольку:

  • Hibernate должен сначала попытаться загрузить телефоны, чтобы увидеть, что их нет.
  • для реализации ленивой загрузки коллекции getPhones() не должен возвращать null, а прокси
  • return null будет плохой практикой в ​​любом случае (список все равно будет существовать, он просто пуст)
  • Если список был пустым, вы не смогли добавить телефон и позволить Hibernate использовать каскадные и т.д., чтобы автоматически сохранить это изменение (спасибо Gimby за указание на то, что )

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