Hibernate
/
hibernate-orm
mirror of https://github.com/hibernate/hibernate-orm
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

"subgraph" and "subtype" are words and do not come with hyphens

This commit is contained in:
Gavin King 2025-01-01 18:15:36 +01:00
parent ae4373dafe
commit 392fc72b31
2 changed files with 13 additions and 13 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
design/working/attributes.adoc
View File

@ -24,7 +24,7 @@ class ForeignCustomer extends Customer {
----
The general idea is that the attributes are ordered alphabetically, super attributes first. Subtypes are sorted
depth-first and the attributes are sorted alphabetically within each sub-type. So the order of the attributes
depth-first and the attributes are sorted alphabetically within each subtype. So the order of the attributes
depends on where we start.
Starting from Customer we have: `[address, name, quota, attr1, attr2, taxId, attr3, attr4, vat]`

24
documentation/src/main/asciidoc/userguide/chapters/fetching/Fetching.adoc
View File

@ -233,7 +233,7 @@ An EntityGraph is the root of a "load plan" and must correspond to an EntityType
[[fetching-strategies-dynamic-fetching-entity-subgraph]]
==== Jakarta Persistence (key) subgraphs
A sub-graph is used to control the fetching of sub-attributes of the AttributeNode it is applied to.
A subgraph is used to control the fetching of sub-attributes of the AttributeNode it is applied to.
It is generally defined via the {jpaJavadocUrlPrefix}NamedSubgraph.html[`@NamedSubgraph`] annotation.
If we have a `Project` parent entity which has an `employees` child associations,
@ -264,24 +264,24 @@ include::{extrasdir}/fetching-strategies-dynamic-fetching-entity-subgraph-exampl
----
====
Specifying a sub-graph is only valid for an attribute (or its "key") whose type is a ManagedType. So
Specifying a subgraph is only valid for an attribute (or its "key") whose type is a ManagedType. So
while an EntityGraph must correspond to an EntityType, a Subgraph is legal for any ManagedType. An
attribute's key is defined as either:
* For a singular attribute, the attribute's type must be an IdentifiableType and that IdentifiableType must
have a composite identifier. The "key sub-graph" is applied to the identifier type. The
non-key sub-graph applies to the attribute's value, which must be a ManagedType.
have a composite identifier. The "key subgraph" is applied to the identifier type. The
non-key subgraph applies to the attribute's value, which must be a ManagedType.
* For a plural attribute, the attribute must be a Map and the Map's key value must be a ManagedType.
The "key sub-graph" is applied to the Map's key type. In this case, the non-key sub-graph applies
The "key subgraph" is applied to the Map's key type. In this case, the non-key subgraph applies
to the plural attribute's value/element.
[[fetching-strategies-dynamic-fetching-entity-subgraph-subtype]]
==== Jakarta Persistence SubGraph sub-typing
SubGraphs can also be sub-type specific. Given an attribute whose value is an inheritance hierarchy,
we can refer to attributes of a specific sub-type using the forms of sub-graph definition that accept
the sub-type Class.
Subgraphs can also be subtype specific. Given an attribute whose value is an inheritance hierarchy,
we can refer to attributes of a specific subtype using the forms of subgraph definition that accept
the subtype Class.
[[fetching-strategies-dynamic-fetching-entity-graph-parsing]]
@ -289,7 +289,7 @@ the sub-type Class.
Hibernate allows the creation of Jakarta Persistence fetch/load graphs by parsing a textual representation
of the graph. Generally speaking, the textual representation of a graph is a comma-separated
list of attribute names, optionally including any sub-graph specifications.
list of attribute names, optionally including any subgraph specifications.
`org.hibernate.graph.GraphParser` is the starting point for such parsing operations.
[NOTE]
@ -312,7 +312,7 @@ This example actually functions exactly as <<fetching-strategies-dynamic-fetchin
just using a parsed graph rather than a named graph.
The syntax also supports defining "key sub-graphs". To specify a key sub-graph, `.key` is added
The syntax also supports defining "key subgraphs". To specify a key subgraph, `.key` is added
to the end of the attribute name.
.Parsing an entity key graph
@ -331,7 +331,7 @@ include::{example-dir-fetching}/GraphParsingTest.java[tags=fetching-strategies-d
----
====
Parsing can also handle sub-type specific sub-graphs. For example, given an entity hierarchy of
Parsing can also handle subtype specific subgraphs. For example, given an entity hierarchy of
`LegalEntity` <- (`Corporation` | `Person` | `NonProfit`) and an attribute named `responsibleParty` whose
type is the `LegalEntity` base type we might have:
@ -342,7 +342,7 @@ responsibleParty(Corporation: ceo)
----
====
We can even duplicate the attribute names to apply different sub-type sub-graphs:
We can even duplicate the attribute names to apply different subtype subgraphs:
====
[source, java, indent=0]