"sub query" -> "subquery"
The word "sub" means "submarine", "submissive", or "substitute". It's never an adjective.
This commit is contained in:
parent
c163e1f2ed
commit
58da5f24f9
|
@ -1473,7 +1473,7 @@ See <<chapters/domain/inheritance.adoc#entity-inheritance-polymorphism>> for mor
|
|||
[[hql-derived-root]]
|
||||
==== Derived root
|
||||
|
||||
As of Hibernate 6.1, HQL allows to declare derived roots, based on a sub query in the `from` clause.
|
||||
As of Hibernate 6.1, HQL allows to declare derived roots, based on a subquery in the `from` clause.
|
||||
|
||||
[[hql-derived-root-example]]
|
||||
====
|
||||
|
|
|
@ -78,7 +78,7 @@ public class HANASqlAstTranslator<T extends JdbcOperation> extends AbstractSqlAs
|
|||
|
||||
@Override
|
||||
protected SqlAstNodeRenderingMode getParameterRenderingMode() {
|
||||
// HANA does not support parameters in lateral sub queries for some reason, so inline all the parameters in this case
|
||||
// HANA does not support parameters in lateral subqueries for some reason, so inline all the parameters in this case
|
||||
return inLateral ? SqlAstNodeRenderingMode.INLINE_ALL_PARAMETERS : super.getParameterRenderingMode();
|
||||
}
|
||||
|
||||
|
|
|
@ -111,7 +111,7 @@ public class AggregateWindowEmulationQueryTransformer implements QueryTransforme
|
|||
// for group by items, since these group by items are migrated to the outer query
|
||||
final Map<Expression, Integer> selectionMapping = new HashMap<>( subSelections.size() );
|
||||
// Create the expressions/selections for the outer query and the columnNames list
|
||||
// for the QueryPartTableGroup within which the sub query spec is embedded
|
||||
// for the QueryPartTableGroup within which the subquery spec is embedded
|
||||
for ( int i = 0; i < subSelections.size(); i++ ) {
|
||||
final BasicValuedMapping mapping = (BasicValuedMapping) subSelections.get( i )
|
||||
.getExpressionType();
|
||||
|
@ -352,7 +352,7 @@ public class AggregateWindowEmulationQueryTransformer implements QueryTransforme
|
|||
subQuerySpec.getSortSpecifications().clear();
|
||||
}
|
||||
|
||||
// We need to add selection items for the expressions we order by to the sub query spec.
|
||||
// We need to add selection items for the expressions we order by to the subquery spec.
|
||||
final int selectionOffset = columnNames.size();
|
||||
// Collect the sorting column references so we can apply the filter later
|
||||
final List<ColumnReference> sortingColumns = new ArrayList<>( withinGroup.size() );
|
||||
|
|
|
@ -15,13 +15,13 @@ import org.hibernate.Incubating;
|
|||
public interface JpaDerivedFrom<T> extends JpaFrom<T,T> {
|
||||
|
||||
/**
|
||||
* The sub query part for this derived from node.
|
||||
* The subquery part for this derived from node.
|
||||
*/
|
||||
JpaSubQuery<T> getQueryPart();
|
||||
|
||||
/**
|
||||
* Specifies whether the sub query part can access previous from node aliases.
|
||||
* Normally, sub queries in the from clause are unable to access other from nodes,
|
||||
* Specifies whether the subquery part can access previous from node aliases.
|
||||
* Normally, subqueries in the from clause are unable to access other from nodes,
|
||||
* but when specifying them as lateral, they are allowed to do so.
|
||||
* Refer to the SQL standard definition of LATERAL for more details.
|
||||
*/
|
||||
|
|
|
@ -30,31 +30,31 @@ public interface JpaSelectCriteria<T> extends AbstractQuery<T>, JpaCriteriaBase
|
|||
JpaQueryPart<T> getQueryPart();
|
||||
|
||||
/**
|
||||
* Create and add a query root corresponding to the given sub query,
|
||||
* Create and add a query root corresponding to the given subquery,
|
||||
* forming a cartesian product with any existing roots.
|
||||
*
|
||||
* @param subquery the sub query
|
||||
* @return query root corresponding to the given sub query
|
||||
* @param subquery the subquery
|
||||
* @return query root corresponding to the given subquery
|
||||
*/
|
||||
<X> JpaDerivedRoot<X> from(Subquery<X> subquery);
|
||||
|
||||
/**
|
||||
* Create and add a query root corresponding to the given lateral sub query,
|
||||
* Create and add a query root corresponding to the given lateral subquery,
|
||||
* forming a cartesian product with any existing roots.
|
||||
*
|
||||
* @param subquery the sub query
|
||||
* @return query root corresponding to the given sub query
|
||||
* @param subquery the subquery
|
||||
* @return query root corresponding to the given subquery
|
||||
*/
|
||||
<X> JpaDerivedRoot<X> fromLateral(Subquery<X> subquery);
|
||||
|
||||
/**
|
||||
* Create and add a query root corresponding to the given sub query,
|
||||
* Create and add a query root corresponding to the given subquery,
|
||||
* forming a cartesian product with any existing roots.
|
||||
* If the sub query is marked as lateral, it may access previous from elements.
|
||||
* If the subquery is marked as lateral, it may access previous from elements.
|
||||
*
|
||||
* @param subquery the sub query
|
||||
* @param lateral whether to allow access to previous from elements in the sub query
|
||||
* @return query root corresponding to the given sub query
|
||||
* @param subquery the subquery
|
||||
* @param lateral whether to allow access to previous from elements in the subquery
|
||||
* @return query root corresponding to the given subquery
|
||||
*/
|
||||
<X> JpaDerivedRoot<X> from(Subquery<X> subquery, boolean lateral);
|
||||
|
||||
|
|
|
@ -62,10 +62,10 @@ public class AnonymousTupleType<T> implements TupleType<T>, DomainType<T>, Retur
|
|||
private static SqmSelectableNode<?>[] extractSqmExpressibles(SqmSubQuery<?> subQuery) {
|
||||
final SqmSelectClause selectClause = subQuery.getQuerySpec().getSelectClause();
|
||||
if ( selectClause == null || selectClause.getSelectionItems().isEmpty() ) {
|
||||
throw new IllegalArgumentException( "Sub query has no selection items!" );
|
||||
throw new IllegalArgumentException( "subquery has no selection items!" );
|
||||
}
|
||||
// todo: right now, we "snapshot" the state of the sub query when creating this type, but maybe we shouldn't?
|
||||
// i.e. what if the sub query changes later on? Or should we somehow mark the sub query to signal,
|
||||
// todo: right now, we "snapshot" the state of the subquery when creating this type, but maybe we shouldn't?
|
||||
// i.e. what if the subquery changes later on? Or should we somehow mark the subquery to signal,
|
||||
// that changes to the select clause are invalid after a certain point?
|
||||
return selectClause.getSelectionItems().toArray( SqmSelectableNode[]::new );
|
||||
}
|
||||
|
|
|
@ -68,7 +68,7 @@ public class QualifiedJoinPredicatePathConsumer extends BasicDotIdentifierConsum
|
|||
return;
|
||||
}
|
||||
}
|
||||
// If the current join is not part of the processing query, this must be a sub query in the ON clause
|
||||
// If the current join is not part of the processing query, this must be a subquery in the ON clause
|
||||
// in which case the path root is allowed to occur in the current processing query as root
|
||||
if ( currentProcessingQuery instanceof SqmSubQuery<?> ) {
|
||||
validateAsRootOnParentQueryClosure( pathRoot, root, processingState );
|
||||
|
@ -96,7 +96,7 @@ public class QualifiedJoinPredicatePathConsumer extends BasicDotIdentifierConsum
|
|||
if ( processingQuery instanceof SqmSelectQuery<?> ) {
|
||||
final SqmQuerySpec<?> querySpec = ( (SqmSelectQuery<?>) processingQuery ).getQuerySpec();
|
||||
final SqmFromClause fromClause = querySpec.getFromClause();
|
||||
// If we are in a sub query, the "foreign" from element could be one of the sub query roots,
|
||||
// If we are in a subquery, the "foreign" from element could be one of the subquery roots,
|
||||
// which is totally fine. The aim of this check is to prevent uses of different "spaces"
|
||||
// i.e. `from A a, B b join b.id = a.id` would be illegal
|
||||
if ( fromClause != null && fromClause.getRoots().contains( root ) ) {
|
||||
|
|
|
@ -5948,7 +5948,7 @@ public abstract class BaseSqmToSqlAstConverter<T extends Statement> extends Base
|
|||
@Override
|
||||
public QueryPart visitSubQueryExpression(SqmSubQuery<?> sqmSubQuery) {
|
||||
// The only purpose for tracking the current join is to
|
||||
// Reset the current join for sub queries because in there, we won't add nested joins
|
||||
// Reset the current join for subqueries because in there, we won't add nested joins
|
||||
final SqmJoin<?, ?> oldJoin = currentlyProcessingJoin;
|
||||
currentlyProcessingJoin = null;
|
||||
final QueryPart queryPart = visitQueryPart( sqmSubQuery.getQueryPart() );
|
||||
|
|
|
@ -1554,7 +1554,7 @@ public abstract class AbstractSqlAstTranslator<T extends JdbcOperation> implemen
|
|||
appendSql( "select" );
|
||||
appendSql( queryGroupAlias );
|
||||
appendSql( ".* from " );
|
||||
// We need to assign aliases when we render a query spec as sub query to avoid clashing aliases
|
||||
// We need to assign aliases when we render a query spec as subquery to avoid clashing aliases
|
||||
this.needsSelectAliases = this.needsSelectAliases || hasDuplicateSelectItems( querySpec );
|
||||
}
|
||||
else if ( !supportsDuplicateSelectItemsInQueryGroup() ) {
|
||||
|
@ -5036,7 +5036,7 @@ public abstract class AbstractSqlAstTranslator<T extends JdbcOperation> implemen
|
|||
if ( queryPart instanceof QuerySpec && queryPart.getFetchClauseExpression() == null
|
||||
&& queryPart.getOffsetClauseExpression() == null ) {
|
||||
subQuery = (QuerySpec) queryPart;
|
||||
// We can only emulate the tuple sub query predicate as exists predicate when there are no limit/offsets
|
||||
// We can only emulate the tuple subquery predicate as exists predicate when there are no limit/offsets
|
||||
if ( negated ) {
|
||||
appendSql( "not " );
|
||||
}
|
||||
|
@ -5130,7 +5130,7 @@ public abstract class AbstractSqlAstTranslator<T extends JdbcOperation> implemen
|
|||
final QuerySpec subQuery;
|
||||
if ( queryPart instanceof QuerySpec && queryPart.getFetchClauseExpression() == null && queryPart.getOffsetClauseExpression() == null ) {
|
||||
subQuery = (QuerySpec) queryPart;
|
||||
// We can only emulate the tuple sub query predicate comparing against the top element when there are no limit/offsets
|
||||
// We can only emulate the tuple subquery predicate comparing against the top element when there are no limit/offsets
|
||||
lhsTuple.accept( this );
|
||||
appendSql( tupleComparisonOperator.sqlText() );
|
||||
|
||||
|
@ -5409,7 +5409,7 @@ public abstract class AbstractSqlAstTranslator<T extends JdbcOperation> implemen
|
|||
}
|
||||
}
|
||||
// If we get here, this is an equality-like comparison, though we support scalar row value comparison
|
||||
// For this special case, we can rely on scalar sub query handling, given that the sub query fetches only one row
|
||||
// For this special case, we can rely on scalar subquery handling, given that the subquery fetches only one row
|
||||
if ( isFetchFirstRowOnly( subquery ) ) {
|
||||
renderComparison( lhsTuple, operator, subquery );
|
||||
return;
|
||||
|
|
|
@ -54,7 +54,7 @@ import static org.junit.jupiter.api.Assertions.assertEquals;
|
|||
public class SubQueryInFromEmbeddedIdTests {
|
||||
|
||||
@Test
|
||||
@FailureExpected(reason = "Support for embedded id association selecting in from clause sub queries not yet supported")
|
||||
@FailureExpected(reason = "Support for embedded id association selecting in from clause subqueries not yet supported")
|
||||
public void testEntity(SessionFactoryScope scope) {
|
||||
scope.inTransaction(
|
||||
session -> {
|
||||
|
@ -100,7 +100,7 @@ public class SubQueryInFromEmbeddedIdTests {
|
|||
}
|
||||
|
||||
@Test
|
||||
@FailureExpected(reason = "Support for embedded id association selecting in from clause sub queries not yet supported")
|
||||
@FailureExpected(reason = "Support for embedded id association selecting in from clause subqueries not yet supported")
|
||||
public void testEntityJoin(SessionFactoryScope scope) {
|
||||
scope.inTransaction(
|
||||
session -> {
|
||||
|
@ -145,7 +145,7 @@ public class SubQueryInFromEmbeddedIdTests {
|
|||
}
|
||||
|
||||
@Test
|
||||
@FailureExpected(reason = "Support for embedded id association selecting in from clause sub queries not yet supported")
|
||||
@FailureExpected(reason = "Support for embedded id association selecting in from clause subqueries not yet supported")
|
||||
public void testEntityImplicit(SessionFactoryScope scope) {
|
||||
scope.inTransaction(
|
||||
session -> {
|
||||
|
|
|
@ -53,7 +53,7 @@ import static org.junit.jupiter.api.Assertions.assertEquals;
|
|||
public class SubQueryInFromIdClassTests {
|
||||
|
||||
@Test
|
||||
@FailureExpected(reason = "Support for id class association selecting in from clause sub queries not yet supported")
|
||||
@FailureExpected(reason = "Support for id class association selecting in from clause subqueries not yet supported")
|
||||
public void testEntity(SessionFactoryScope scope) {
|
||||
scope.inTransaction(
|
||||
session -> {
|
||||
|
@ -99,7 +99,7 @@ public class SubQueryInFromIdClassTests {
|
|||
}
|
||||
|
||||
@Test
|
||||
@FailureExpected(reason = "Support for id class association selecting in from clause sub queries not yet supported")
|
||||
@FailureExpected(reason = "Support for id class association selecting in from clause subqueries not yet supported")
|
||||
public void testEntityJoin(SessionFactoryScope scope) {
|
||||
scope.inTransaction(
|
||||
session -> {
|
||||
|
@ -144,7 +144,7 @@ public class SubQueryInFromIdClassTests {
|
|||
}
|
||||
|
||||
@Test
|
||||
@FailureExpected(reason = "Support for id class association selecting in from clause sub queries not yet supported")
|
||||
@FailureExpected(reason = "Support for id class association selecting in from clause subqueries not yet supported")
|
||||
public void testEntityImplicit(SessionFactoryScope scope) {
|
||||
scope.inTransaction(
|
||||
session -> {
|
||||
|
|
|
@ -291,7 +291,7 @@ abstract public class DialectChecks {
|
|||
public static class SupportsOrderByInCorrelatedSubquery implements DialectCheck {
|
||||
public boolean isMatch(Dialect dialect) {
|
||||
return dialect.supportsOrderByInSubquery()
|
||||
// For some reason, HANA doesn't support order by in correlated sub queries...
|
||||
// For some reason, HANA doesn't support order by in correlated subqueries...
|
||||
&& !( dialect instanceof AbstractHANADialect );
|
||||
}
|
||||
}
|
||||
|
|
|
@ -359,7 +359,7 @@ abstract public class DialectFeatureChecks {
|
|||
public static class SupportsOrderByInCorrelatedSubquery implements DialectFeatureCheck {
|
||||
public boolean apply(Dialect dialect) {
|
||||
return dialect.supportsOrderByInSubquery()
|
||||
// For some reason, HANA doesn't support order by in correlated sub queries...
|
||||
// For some reason, HANA doesn't support order by in correlated subqueries...
|
||||
&& !( dialect instanceof AbstractHANADialect );
|
||||
}
|
||||
}
|
||||
|
|
Loading…
Reference in New Issue