In general fetchLocation is available for "normal" scans, but obviously not available for when store returns bulk set of rows back in the form of a hash table. also GroupFetchScanController have special interfaces to return the RowLocation.
Is your problem specific to hash table returns, or are there other cases where fetchLocation from a ScanController does not work? On 10/1/2013 10:29 AM, Rick Hillegas wrote:
I need some advice about how to design an api for requesting that the Store include RowLocations in the rows that it scans and hands back to the language layer. The immediate problem that I'm working on involves implementing the MERGE statement (DERBY-3155). Part of the implementation involves cooking up a left join between two tables. I need to get back RowLocations for the right table of that join. In a particular problem case which I'm examining, the optimizer picks a HashJoin strategy for the left join. That turns into a HashLeftOuterJoinResultSet at execution time. And that, in turn, involves having the Store create and fill a BackingStoreHashTableFromScan. The BackingStoreHashTableFromScan is created with a scanColumnList (a FormatableBitSet) which specifies some actual columns in the row as well as a trailing column position which is meant to represent the RowLocation. That trailing column position is represented as 1 plus the actual row length. BackingStoreHashTableFromScan doesn't know what to make of that column position and silently ignores it. So clearly either that's the wrong api for asking for RowLocations or BackingStoreHashTableFromScan needs to be taught some new tricks. So the question is this: what's the right way to ask BackingStoreHashTableFromScan to build a hash table whose rows contain some set of real column positions plus a trailing RowLocation column? I may stumble into other situations where I need to ask a scan to put RowLocations into the rows it returns. So it would be good to have a general pattern here for requesting this special column. Thanks, -Rick
