[
https://issues.apache.org/jira/browse/DERBY-3155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13790423#comment-13790423
]
Mike Matrigali commented on DERBY-3155:
---------------------------------------
start of detail review:
initial high level thought on store api changes, still looking at detail code.
nits: in LocatedRow: some code more than 80 char line. not sure where derby
code standard is, but I find reading 1-line for loops and 1 line procedures
distracting.
BackingStoreHashTable:
+unnecessary +80 col lines
+should look at interface and see if external users of this class actually
need to know the format of data spilled to disk. If this were private to the
implementation then maybe it is less a problem to add the rowlocation to end of
row on write to disk and read back from disk. maybe a comment in the routine
that creates a BackingStoreHashtable from a rowsource that is never creates the
"new" style hash table (or should it be paying attention to include row
source?) It is kind of ugly already that there is implementation code in the
interface - but that is an existing problem - not anything you added.
+ the following call is extra per row in the new code, and is not needed for
non-merge system:
Object hashValue = makeHashValue( columnValues, rowLocation );
maybe some comments why it ok to pass hashValue into the space accounting
rather than row. I think it is ok, just lost the logic while reading - i think
hashValue has the row in it at this point.
more single line if body else body
as far in detail i got though patch so far (around line 300 of 1000).
> 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)
