Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Date: Tue, 22 Oct 2013 17:54:45 +0000 (UTC)
From: "Mike Matrigali (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Message-ID: <JIRA.12381347.1193611780298.105227.1382464485901@arcas>
In-Reply-To: <JIRA.12381347.1193611780298@arcas>
References: <JIRA.12381347.1193611780298@arcas>
Subject: [jira] [Commented] (DERBY-3155) Support for SQL:2003 MERGE
 statement
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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