[
https://issues.apache.org/jira/browse/DERBY-3155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13790467#comment-13790467
]
Rick Hillegas commented on DERBY-3155:
--------------------------------------
Hi Mike,
Thanks for the initial review of
derby-3155-03-ae-backingStoreHashtableWithRowLocation.diff. Some responses
follow:
1) You have put your finger on the big design problem for
BackingStoreHashtable: the desire for code re-use vs. the desire to not perturb
the existing code path. These were the options I considered:
a) Clone BackingStoreHashtable in order to create a new implementation just for
RowLocations.
+ With this solution, it's easy to prove to yourself that the existing code
path is not perturbed.
- This is a very large, complicated class to begin with. I did not want to
multiply the code complexity by 2. Cloning creates the brittle situation where
even experts can forget to apply a bug fix in two parallel places.
b) Add the RowLocation support inline inside the existing BackingStoreHashtable.
+ The additional code complexity and brittleness is minimal.
- However, the existing code path is perturbed.
c) Subclass BackingStoreHashtable.
+ This would add less complexity to the existing code path than (b).
- This is probably less brittle than (a) but more brittle than (b).
- The additional overhead for the existing code path is pretty much the same as
for (b). Basically some conditional blocks could be turned into method calls.
- But now BackingStoreHashTableFromScan would probably need to be subclassed
too. We would have 4 classes doing the job of 1.
d) Subclass BackingStoreHashTableFromScan.
+/ This has pretty much the same advantages and disadvantages as (c). In
addition...
- This would make it more difficult to add support for RowLocations to hash
tables which AREN'T driven by scans.
e) Instead of subclassing BackingStoreHashTableFromScan, just add some new
methods to it.
+/ This has pretty much the same advantages and disadvantages as (d). In
addition...
+ Creates 1 fewer class.
To summarize:
(a) I rejected this option because it seemed too complex.
(b) I settled on this option because it seemed to strike the best balance
between complexity and performance. I do think that the additional overhead for
the existing code path is not measurable.
(c) I rejected this option because it seemed too complex.
(d) (e) I rejected these because of the difficulty they pose for adding future
RowLocation support to hash tables which AREN'T driven by scans.
Other suggestions are certainly welcome!
2) As you note, LocatedRow contains the logic for appending the RowLocation
onto the end of a DataValueDescriptor[]. The logic is indeed needed by the
language layer. But it's also needed by BackingStoreHashtable when it spills
rows to disk. These were the options I considered:
a) Put the logic in LocatedRow, where it can be shared by both the language and
Store layers.
b) Put the logic somewhere else, where it can be shared.
c) Clone the logic, keeping one copy of the code in the language layer and
another copy in the Store.
In the interests of reduced complexity and brittleness, I thought that (a) was
the best choice. But other suggestions are certainly welcome.
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,
> 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)
