Блог

У меня есть следующие сопоставления объектов для моего приложения EJB3, которые отображают отношения «многие ко многим»:

 @Entity
Crawl{
    @OneToMany(fetch = FetchType.EAGER, mappedBy = "pk.crawl")
    public List<Change> changes;
}

@Entity
Change{
    @EmbeddedId
    ChangePK pk;
    @Temporal(javax.persistence.TemporalType.DATE)
    Date changeDate;
}

@Embeddable
ChangePK{
    @ManyToOne
    Crawl crawl;

    @ManyToOne
    Page page;
}

@Entity
Page{
    @OneToMany(fetch = FetchType.LAZY, mappedBy = "pk.page")
    List<Change> changes;
}
  

Я пытаюсь получить все изменения, связанные с обходом, и упорядочить их по дате, используя:

 this.entityManager
    .createQuery("SELECT c FROM Change c WHERE 
                  c.pk.crawl.id = :id 
                  ORDER BY c.changeDate DESC")
   .setParameter("id", crawl.getId());
  

Это выдает мне ошибку переполнения стека. Я полагаю, что нетерпеливая выборка может иметь к этому какое-то отношение, но в любом другом случае я хочу, чтобы изменения загружались с обходом, и это вызовет много проблем в остальной части моего приложения, если я изменю тип выборки на lazy.

Я переопределил методы hashCode и equals для каждого класса.

Редактировать:

hashcode и equals код:

 @Override
public int hashCode() {
    final int prime = 31;
    int result = 1;
    result = prime * result   id;
    return resu<
}

@Override
public boolean equals(Object obj) {
    if (obj == null)
        return false;
    if (getClass() != obj.getClass())
        return false;
    Crawl other = (Crawl) obj;
    if (id != other.id)
        return false;
    return true;
}
  

Они генерируются Eclipse, и я выбрал первичные ключи для использования в них, все другие классы используют то же самое.

Если все дерево дерева объектов большое, нет способа * избежать stackoverflow, поскольку hibernate рекурсивно разрешает зависимости, что нормально для 99,9% случаев (за 8 лет использования hibernate я впервые вижу эту ошибку).

Одной из альтернатив для исправления этого является увеличение размера стека, но это увеличит размер во всех потоках приложения (что может быть не очень хорошо). так, например, вы можете добавить опцию -Xss1m при запуске JVM, и вы получите размер стека в 1 мб. (размер стека по умолчанию варьируется от платформы к платформе, но я думаю, что обычно это 512 кб)

Другой альтернативой является изменение сопоставления, но я думаю, что все они включают небольшую денормализацию таблицы. Один из вариантов — сгладить дерево, чтобы при определенном обходе вы могли получить все дочерние элементы обхода одним запросом. В этом случае обход коллекции.changes содержит все дочерние элементы, внуков и т.д. обхода.

* всегда есть способ