[
https://issues.apache.org/jira/browse/DERBY-3155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13802063#comment-13802063
]
Mike Matrigali commented on DERBY-3155:
---------------------------------------
overall comments:
i am fine with approach and implementation.
would like to understand the includeLocations use in the code, if this is in
progress or what is expected for whole project.
might be good to add an assert somewhere if code tries to ask for a RowLocation
on a btree, or at least understand what
happens in checked in code if that happened.
Here are file by file, mostly just more style and 80 char comments - and
content comments are about the above question:
Index: java/storeless/org/apache/derby/impl/storeless/NoOpTransaction.java
no comments.
java/engine/org/apache/derby/iapi/types/LocatedRow.java (revision 0)
no comments.
Index: java/engine/org/apache/derby/iapi/store/access/BackingStoreHashtable.java
psuedo code in BackingStoreHashTable javdoc is not right anymore, it shows row
as being Object[]. Not sure if the hash description is right or not still.
nit: comments added, over 80 char line
this comment is confusing to me:
Currently, if the RowSource is not null, then there is no su
pport for including RowLocations in the returned rows. That functionality is
only supported for scans from base tables.
I think BackingStoreHashTable constructor action is now dependent on info
provided from the passed in row source, some comment on that would help - which
may be what the above is trying to say.
is it right that includeRowLocations is hard coded to return false?
nit: the following style still in code (this could just be my issue):
+ if ( !includeRowLocations() )
+ { return diskRow; }
+ else { return new LocatedRow( diskRow ); }
I think the 2 acceptable forms are either:
if ( !includeRowLocations() )
{
return diskRow;
}
else
{
return new LocatedRow( diskRow );
}
if ( !includeRowLocations() ) {
return diskRow;
} else {
return new LocatedRow( diskRow );
}
Index: java/engine/org/apache/derby/iapi/store/access/TransactionController.java
nit: over 80 char lines
Index: java/engine/org/apache/derby/iapi/store/build.xml
no comments.
Index: java/engine/org/apache/derby/impl/sql/execute/DistinctScanResultSet.java
no comments
Index: java/engine/org/apache/derby/impl/sql/execute/HashScanResultSet.java
no comments
Index: java/engine/org/apache/derby/impl/sql/execute/NoPutResultSetImpl.java
nit: single line code style
no other comments
Index: java/engine/org/apache/derby/impl/sql/execute/ScrollInsensitiveResultSet.
java
no comments, not reviewed.
Index: java/engine/org/apache/derby/impl/sql/execute/UpdateResultSet.java
no comments
Index: java/engine/org/apache/derby/impl/store/access/conglomerate/GenericScanCo
ntroller.java
nit: over 80 char
Index: java/engine/org/apache/derby/impl/store/access/BackingStoreHashTableFromS
can.java
no comments
Index: java/engine/org/apache/derby/impl/store/access/btree/BTreeForwardScan.jav
a
no comments.
Index: java/engine/org/apache/derby/impl/store/access/RAMTransaction.java
no comments.
Index: java/engine/org/apache/derby/impl/store/access/heap/HeapScan.java
no comments.
Index: java/testing/org/apache/derbyTesting/unitTests/store/T_QualifierTest.java
no comments.
> 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)
