[
https://issues.apache.org/jira/browse/DERBY-3155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13802082#comment-13802082
]
Rick Hillegas commented on DERBY-3155:
--------------------------------------
Hi Mike,
Responding to your first comment:
If someone needs RowLocations in RowSource-driven hash tables, then they are
welcome to add that functionality. I was not planning to add that functionality
as part of this effort.
BackingStoreHashtables appear to be created in two ways right now:
1) Directly by invoking the BackingStoreHashtable constructor.
2) Indirectly by calling
TransactionController.createBackingStoreHashtableFromScan().
In the execution layer, ScrollInsensitiveResultSet and UpdateResultSet directly
create BackingStoreHashtables with null RowSource arguments. Also in the
execution layer, HashTableResultSet directly creates a BackingStoreHashtable
with a RowSource which is itself, that is, essentially a filtered version of
its child node (and therefore not a scan).
In the Store layer, BackingStoreHashTableFromScan directly invokes the
BackingStoreHashtable constructor (its superclass) with a null RowSource.
RAMTransaction.createBackingStoreHashtableFromScan() itself constructs a
BackingStoreHashTableFromScan and therefore the RowSource is null.
So I am only seeing one code path where a non-null RowSource is specified. That
is in HashTableResultSet. But I must be missing something because your question
implies that these are created by index scans.
Thanks,
-Rick
> Support for SQL:2003 MERGE statement
> ------------------------------------
>
> Key: DERBY-3155
> URL: https://issues.apache.org/jira/browse/DERBY-3155
> Project: Derby
> Issue Type: Improvement
> Components: SQL
> Reporter: Trejkaz
> Assignee: Rick Hillegas
> Labels: derby_triage10_10
> Attachments: derby-3155-01-ac-grammar.diff,
> derby-3155-02-ag-fixParserWarning.diff,
> derby-3155-03-ae-backingStoreHashtableWithRowLocation.diff,
> derby-3155-03-af-backingStoreHashtableWithRowLocation.diff,
> derby-3155-04-ae-deleteAction.diff, MergeStatement.html, MergeStatement.html,
> MergeStatement.html
>
>
> A relatively common piece of logic in a database application is to check for
> a row's existence and then either update or insert depending on its existence.
> SQL:2003 added a MERGE statement to perform this operation. It looks like
> this:
> MERGE INTO table_name USING table_name ON (condition)
> WHEN MATCHED THEN UPDATE SET column1 = value1 [, column2 = value2 ...]
> WHEN NOT MATCHED THEN INSERT column1 [, column2 ...] VALUES (value1 [,
> value2 ...])
> At the moment, the only workaround for this would be to write a stored
> procedure to do the same operation, or to implement the logic client-side.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
