[
https://issues.apache.org/jira/browse/DERBY-3155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13790542#comment-13790542
]
Rick Hillegas commented on DERBY-3155:
--------------------------------------
Hi Mike,
Thanks for the second set of comments on
derby-3155-03-ae-backingStoreHashtableWithRowLocation.diff. I'm happy to make
the formatting changes you suggest. Some more responses follow:
> 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.
I may not understand this question, but here are some more thoughts:
The api for BackingStoreHashtable has certainly become uglier. We go from a bad
situation where BackingStoreHashtable can return 2 kinds of objects and the
calling code has to figure out the type of what's being retrieved. The 2 types
are...
i) Rows
ii) Buckets of rows
...and the patch takes us to a situation where BackingStoreHashtable can now
return 4 types of objects:
i) Rows
ii) Buckets of rows
iii) LocatedRows
iv) Buckets of LocatedRows
It might be cleaner if the existing methods always returned buckets of rows and
if we added some new methods to return buckets of LocatedRows. However, a
change like this would perturb more code. In addition, wrapping single rows in
vacuous buckets might result in a measurable performance hit on old code paths.
> 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.
This sounds like a good idea.
> 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.
Adding a comment sounds like a good idea. The point of the code is this: Space
accounting is responsible for calculating how much space is taken up by the
whole value which is stored in the hash table. For rows which don't have
RowLocations, the value is just a row (a DataValueDescriptor[]). But for
LocatedRows, there is some additional space consumed by the RowLocation and by
the wrapping LocatedRow object.
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)
