Class MultiProbeTableScanResultSet

  • All Implemented Interfaces:
    java.lang.Cloneable, CursorResultSet, NoPutResultSet, ResultSet, RowLocationRetRowSource, RowSource

    class MultiProbeTableScanResultSet
    extends TableScanResultSet
    implements CursorResultSet
    Result set that fetches rows from a scan by "probing" the underlying table with a given list of values. Repeated calls to getNextRowCore() will first return all rows matching probeValues[0], then all rows matching probeValues[1], and so on (duplicate probe values are ignored). Once all matching rows for all values in probeValues have been returned, the call to getNextRowCore() will return null, thereby ending the scan. The expectation is that this kind of result set only ever appears beneath some other top-level result set (esp. IndexRowToBaseRowResultSet), in which case all result sets higher up in the result set tree will just see a stream of rows satisfying the list of probe values. Currently this type of result is used for evaluation of IN lists, where the user wants to retrieve all rows for which some target column has a value that equals one of values in the IN list. In that case the IN list values are represented by the probeValues array. Most of the work for this class is inherited from TableScanResultSet. This class overrides four public methods and two protected methods from TableScanResultSet. In all cases the methods here set probing state and then call the corresponding methods on "super".
    • Field Detail

      • probeValues

        protected DataValueDescriptor[] probeValues
        The values with which we will probe the table.
      • origProbeValues

        protected DataValueDescriptor[] origProbeValues
        The values with which we will probe the table, as they were passed to the constructor. We need to keep them unchanged in case the result set is reused when a statement is re-executed (see DERBY-827).
      • probeValIndex

        protected int probeValIndex
        0-based position of the next value to lookup w.r.t. the probe values list.
      • sortRequired

        private int sortRequired
        Indicator as to which type of sort we need: ASCENDING, DESCENDING, or NONE (NONE is represented by "RowOrdering.DONTCARE" and is used for cases where all necessary sorting occurred at compilation time).
      • skipNextScan

        private boolean skipNextScan
        Tells whether or not we should skip the next attempt to (re)open the scan controller. If it is true it means that the previous call to initStartAndStopKey() did not find a new probe value, which means that the probe list is exhausted and we shouldn't perform a scan.
    • Method Detail

      • reopenCore

        private void reopenCore​(boolean forNextProbe)
                         throws StandardException
        There are two scenarios for which we reopen this kind of scan: A - The first is for join processing. In this case we have a(nother) row from some outer table and we want to reopen this scan to look for rows matching the new outer row. B - The second is for multi-probing. Here we want to reopen the scan on this table to look for rows matching the next value in the probe list. If we are reopening the scan for scenario A (join processing) then we need to reset our position within the probe list. If we are reopening the scan for scenario B then we do *not* want to reset our position within the probe list because that position tells us where to find the next probe value. That said, this method does the work of reopenCore() using the received boolean to determine which of the two scenarios we are in. Note that if our current position (i.e. the value of probeValIndex) is beyond the length of the probe list then we know that we are reopening the scan for scenario A. Or put another away, we should never get here for scenario B if probeValIndex is greater than or equal to the length of the probe list. The reason is that the call to reopenCore() for scenario B will only ever happen when moreInListVals() returns true--and in that case we know that probeValIndex will be less than the length of the probeValues. But the opposite is not true: i.e. it is *not* safe to say that a probeValIndex which is less than the length of probe list is always for scenario B. That's not true because it's possible that the join to which this scan belongs is a "oneRowRightSide" join, meaning that this, the "right" side scan, will be "interrupted" after we return a single row for the current outer row. If we then come back with a new outer row we need to reset our position-- even though probeValIndex will be less than probeValues.length in that case. DERBY-3603.
        Throws:
        StandardException
      • initStartAndStopKey

        void initStartAndStopKey()
                          throws StandardException
        Initialize the start key and the stop key used in the scan. Both keys will be set to the probe value. If no new probe value was found (the probe list was exhausted), the flag skipNextScan will be true when the method returns to prevent a new scan from being reopened with a missing or incorrect probe value.
        Overrides:
        initStartAndStopKey in class TableScanResultSet
        Throws:
        StandardException
      • getNextRowCore

        public ExecRow getNextRowCore()
                               throws StandardException
        Return the next row (if any) from the scan (if open). More specifically we do the following: 1 - See if we have a row to read from the current scan position. If so, return that row (done). 2 - If there are no more rows to read from the current scan position AND if there are more probe values to look at, then a) reposition the scan using the next probe value as the start/stop key and b) go back to step 1. Otherwise proceed to step 3. 3 - Return null (no more rows). Note that step 1 is important for cases where multiple rows in this table match a single probe value. In such a scenario we have to be sure that we do *not* move on to the next probe value until we have returned all of the rows for the _current_ probe value.
        Specified by:
        getNextRowCore in interface NoPutResultSet
        Overrides:
        getNextRowCore in class TableScanResultSet
        Returns:
        the next row in the result
        Throws:
        StandardException - thrown on failure to get next row
        See Also:
        NoPutResultSet.getNextRowCore()
      • moreInListVals

        private boolean moreInListVals()
        Figure out whether or not we can (re-)position the scan controller based on the next value in probeValues. This will return false when we have exhausted the probe list (i.e. when we've gone through all of the values).
      • getNextProbeValue

        private DataValueDescriptor getNextProbeValue()
        Return the next non-duplicate value from the probe list. Assumption is that the list is sorted so that duplicates appear next to each other, and that probeValIndex is the index of the next value. If we've exhausted the probe list then just return null.