db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rick Hillegas (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DERBY-3155) Support for SQL:2003 MERGE statement
Date Tue, 22 Oct 2013 18:22:47 GMT

    [ 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)

Mime
View raw message