Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>For me the trick was to use many-to-many relationship. Suppose that your entity A is a division that can have sub-divisions. Then (skipping irrelevant details):</p> <pre><code>@Entity @Table(name = "DIVISION") @EntityListeners( { HierarchyListener.class }) public class Division implements IHierarchyElement { private Long id; @Id @Column(name = "DIV_ID") public Long getId() { return id; } ... private Division parent; private List&lt;Division&gt; subDivisions = new ArrayList&lt;Division&gt;(); ... @ManyToOne @JoinColumn(name = "DIV_PARENT_ID") public Division getParent() { return parent; } @ManyToMany @JoinTable(name = "DIVISION", joinColumns = { @JoinColumn(name = "DIV_PARENT_ID") }, inverseJoinColumns = { @JoinColumn(name = "DIV_ID") }) public List&lt;Division&gt; getSubDivisions() { return subDivisions; } ... } </code></pre> <p>Since I had some extensive business logic around hierarchical structure and JPA (based on relational model) is very weak to support it I introduced interface <code>IHierarchyElement</code> and entity listener <code>HierarchyListener</code>:</p> <pre><code>public interface IHierarchyElement { public String getNodeId(); public IHierarchyElement getParent(); public Short getLevel(); public void setLevel(Short level); public IHierarchyElement getTop(); public void setTop(IHierarchyElement top); public String getTreePath(); public void setTreePath(String theTreePath); } public class HierarchyListener { @PrePersist @PreUpdate public void setHierarchyAttributes(IHierarchyElement entity) { final IHierarchyElement parent = entity.getParent(); // set level if (parent == null) { entity.setLevel((short) 0); } else { if (parent.getLevel() == null) { throw new PersistenceException("Parent entity must have level defined"); } if (parent.getLevel() == Short.MAX_VALUE) { throw new PersistenceException("Maximum number of hierarchy levels reached - please restrict use of parent/level relationship for " + entity.getClass()); } entity.setLevel(Short.valueOf((short) (parent.getLevel().intValue() + 1))); } // set top if (parent == null) { entity.setTop(entity); } else { if (parent.getTop() == null) { throw new PersistenceException("Parent entity must have top defined"); } entity.setTop(parent.getTop()); } // set tree path try { if (parent != null) { String parentTreePath = StringUtils.isNotBlank(parent.getTreePath()) ? parent.getTreePath() : ""; entity.setTreePath(parentTreePath + parent.getNodeId() + "."); } else { entity.setTreePath(null); } } catch (UnsupportedOperationException uoe) { LOGGER.warn(uoe); } } } </code></pre>
    singulars
    1. This table or related slice is empty.
    1. POJPA: How to have one-to-many relation of the same Entity type
      singulars
      1. PTQuestion
    1. PTAnswer
    1. UStopchef
    1. UStopchef
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. COWhy not use the simpler @OneToMany(mappedBy="DIV_PARENT_ID") instead of @ManyToMany(...) with self-referencing attributes? Retyping table and column names like that violates DRY. Maybe there's a reason for that, but I don't see it. Also, the EntityListener example is neat but non-portable, assuming `Top` is a relationship. Page 93 of the JPA 2.0 spec, Entity Listeners and Callback Methods: "In general, the lifecycle method of a portable application should not invoke EntityManager or Query operations, access other entity instances, or modify relationships". Right? Let me know if I'm off.
      singulars
      1. PO
      1. USDan LaRocque
    2. COMy solution is 3 years old using JPA 1.0. I adapted it unchanged from the production code. I am sure I could take out some columns names but it wasn't the point. Your answer does it exactly and simpler, not sure why I used many-to-many back then - but it does work and I am confident that more complex solution was there for a reason. Though, I'll have to revisit this now.
      singulars
      1. PO
      1. UStopchef
    3. COYes, top is a self-reference, hence a relationship. Strictly speaking, I don't modify it - just initialize. Also, it's unidirectional so there is no dependency the other way around, it doesn't reference other entities besides self. Per your quote spec has "in general" which means that it's not strict definition. I believe that in this case there is very low portability risk if any.
      singulars
      1. PO
      1. UStopchef
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload