Interface ScrollableResultSetProcessor


  • public interface ScrollableResultSetProcessor
    Contract for processing JDBC ResultSets a single logical row at a time. These are intended for use by ScrollableResults implementations. NOTE : these methods initially taken directly from Loader counterparts in an effort to break Loader into manageable pieces, especially in regards to the processing of result sets.
    • Method Detail

      • extractSingleRow

        Object extractSingleRow​(ResultSet resultSet,
                                SessionImplementor session,
                                QueryParameters queryParameters)
        Give a ResultSet, extract just a single result row. Copy of org.hibernate.loader.Loader#loadSingleRow(java.sql.ResultSet, org.hibernate.engine.spi.SessionImplementor, org.hibernate.engine.spi.QueryParameters, boolean) but dropping the 'returnProxies' (that method has only one use in the entire codebase and it always passes in false...)
        Parameters:
        resultSet - The result set being processed.
        session - The originating session
        queryParameters - The "parameters" used to build the query
        Returns:
        The extracted result row
        Throws:
        HibernateException - Indicates a problem extracting values from the result set.
      • extractLogicalRowForward

        Object extractLogicalRowForward​(ResultSet resultSet,
                                        SessionImplementor session,
                                        QueryParameters queryParameters)
        Given a scrollable ResultSet, extract a logical row. The assumption here is that the ResultSet is already properly ordered to account for any to-many fetches. Multiple ResultSet rows are read into a single query result "row". Copy of org.hibernate.loader.Loader#loadSequentialRowsForward(java.sql.ResultSet, org.hibernate.engine.spi.SessionImplementor, org.hibernate.engine.spi.QueryParameters, boolean) but dropping the 'returnProxies' (that method has only one use in the entire codebase and it always passes in false...)
        Parameters:
        resultSet - The result set being processed.
        session - The originating session
        queryParameters - The "parameters" used to build the query
        Returns:
        The extracted result row
        Throws:
        HibernateException - Indicates a problem extracting values from the result set.
      • extractLogicalRowReverse

        Object extractLogicalRowReverse​(ResultSet resultSet,
                                        SessionImplementor session,
                                        QueryParameters queryParameters,
                                        boolean isLogicallyAfterLast)
        Like extractLogicalRowForward(java.sql.ResultSet, org.hibernate.engine.spi.SessionImplementor, org.hibernate.engine.spi.QueryParameters) but here moving through the ResultSet in reverse. Copy of org.hibernate.loader.Loader#loadSequentialRowsReverse(java.sql.ResultSet, org.hibernate.engine.spi.SessionImplementor, org.hibernate.engine.spi.QueryParameters, boolean, boolean) but dropping the 'returnProxies' (that method has only one use in the entire codebase and it always passes in false...). todo : is 'logicallyAfterLastRow really needed? Can't that be deduced? In fact pretty positive it is not needed.
        Parameters:
        resultSet - The result set being processed.
        session - The originating session
        queryParameters - The "parameters" used to build the query
        isLogicallyAfterLast - Is the result set currently positioned after the last row; again, is this really needed? How is it any diff
        Returns:
        The extracted result row
        Throws:
        HibernateException - Indicates a problem extracting values from the result set.