Examples of CollectionQuerySpace


Examples of org.hibernate.loader.plan2.spi.CollectionQuerySpace

    if ( leftHandSideTableAlias == null ) {
      throw new IllegalStateException( "QuerySpace with that UID was not yet registered in the AliasResolutionContext" );
    }
    final String[] aliasedLhsColumnNames = join.resolveAliasedLeftHandSideJoinConditionColumns( leftHandSideTableAlias );

    final CollectionQuerySpace rightHandSide = (CollectionQuerySpace) join.getRightHandSide();
    final CollectionReferenceAliases aliases = aliasResolutionContext.generateCollectionReferenceAliases(
        rightHandSide.getUid(),
        rightHandSide.getCollectionPersister()
    );

    // The SQL join to the "collection table" needs to be rendered.
    //
    // In the case of a basic collection, that's the only join needed.
    //
    // For one-to-many/many-to-many, we need to render the "collection table join"
    // here (as already stated). There will be a follow-on join (rhs will have a join) for the associated entity.
    // For many-to-many, the follow-on join will join to the associated entity element table. For one-to-many,
    // the collection table is the associated entity table, so the follow-on join will not be rendered..

    if ( rightHandSide.getCollectionPersister().isOneToMany()
        || rightHandSide.getCollectionPersister().isManyToMany() ) {
      // relatedly, for collections with entity elements (one-to-many, many-to-many) we need to register the
      // sql aliases to use for the entity.
      //
      // currently we do not explicitly track the joins under the CollectionQuerySpace to know which is
      // the element join and which is the index join (maybe we should?).  Another option here is to have the
      // "collection join" act as the entity element join in this case (much like I do with entity identifiers).
      // The difficulty there is that collections can theoretically could be multiple joins in that case (one
      // for element, one for index).  However, that's a bit of future-planning as today Hibernate does not
      // properly deal with the index anyway in terms of allowing dynamic fetching across a collection index...
      //
      // long story short, for now we'll use an assumption that the last join in the CollectionQuerySpace is the
      // element join (that's how the joins are built as of now..)
      //
      // todo : remove this assumption ^^; maybe we make CollectionQuerySpace "special" and rather than have it
      // hold a list of joins, we have it expose the 2 (index, element) separately.

      Join collectionElementJoin = null;
      for ( Join collectionJoin : rightHandSide.getJoins() ) {
        collectionElementJoin = collectionJoin;
      }
      if ( collectionElementJoin == null ) {
        throw new IllegalStateException(
            String.format(
                "Could not locate collection element join within collection join [%s : %s]",
                rightHandSide.getUid(),
                rightHandSide.getCollectionPersister()
            )
        );
      }
      aliasResolutionContext.registerQuerySpaceAliases(
          collectionElementJoin.getRightHandSide().getUid(),
View Full Code Here

Examples of org.hibernate.loader.plan2.spi.CollectionQuerySpace

          compositeQuerySpace.getClass().getSimpleName(),
          compositeQuerySpace.getUid()
      );
    }
    else if ( CollectionQuerySpace.class.isInstance( space ) ) {
      final CollectionQuerySpace collectionQuerySpace = (CollectionQuerySpace) space;
      return String.format(
          "%s(uid=%s, collection=%s)",
          collectionQuerySpace.getClass().getSimpleName(),
          collectionQuerySpace.getUid(),
          collectionQuerySpace.getCollectionPersister().getRole()
      );
    }
    return space.toString();
  }
View Full Code Here
TOP
Copyright © 2018 www.massapi.com. All rights reserved.
All source code are property of their respective owners. Java is a trademark of Sun Microsystems, Inc and owned by ORACLE Inc. Contact coftware#gmail.com.