[
https://issues.apache.org/jira/browse/PHOENIX-476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15600941#comment-15600941
]
Hadoop QA commented on PHOENIX-476:
-----------------------------------
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12834870/PHOENIX-476.10.patch
against master branch at commit 8f5c8cfbd1c1f7894e4cc88e2257d245d1d8c3bf.
ATTACHMENT ID: 12834870
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 3 new
or modified tests.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:red}-1 javadoc{color}. The javadoc tool appears to have generated
43 warning messages.
{color:red}-1 release audit{color}. The applied patch generated 1 release
audit warnings (more than the master's current 0 warnings).
{color:red}-1 lineLengths{color}. The patch introduces the following lines
longer than 100:
+ conn.createStatement().executeQuery("SELECT c1 FROM " +
sharedTable2 + " WHERE c1 = 10");
+ rs = conn.createStatement().executeQuery("SELECT c4 FROM " +
sharedTable2 + " WHERE c4 = 'ABCD'");
+ : c=column_name dt=identifier (LPAREN l=NUMBER (COMMA s=NUMBER)?
RPAREN)? ar=ARRAY? (lsq=LSQUARE (a=NUMBER)? RSQUARE)? (nn=NOT? n=NULL)?
(DEFAULT df=expression)? (pk=PRIMARY KEY (order=ASC|order=DESC)?
rr=ROW_TIMESTAMP?)?
+ protected RegionScanner doPostScannerOpen(final
ObserverContext<RegionCoprocessorEnvironment> c, final Scan scan, final
RegionScanner s) throws IOException, SQLException {
+ CANNOT_CREATE_DEFAULT_ROWTIMESTAMP(1032, "42Y90", "Cannot create
ROW_TIMESTAMP column with a default value."),
+ public ColumnDef columnDef(ColumnName columnDefName, String sqlTypeName,
boolean isArray, Integer arrSize, Boolean isNull, Integer maxLength, Integer
scale, boolean isPK,
+ public Expression newColumnExpression(boolean schemaNameCaseSensitive,
boolean colNameCaseSensitive) throws SQLException {
+ columnDefs.add(FACTORY.columnDef(colName,
col.getDataType().getSqlTypeName(), col.isNullable(), col.getMaxLength(),
col.getScale(), false, col.getSortOrder(), col.getExpressionStr(),
col.isRowTimestamp()));
+ PColumn newColumn = new PColumnImpl(oldColumn.getName(),
oldColumn.getFamilyName(), oldColumn.getDataType(), oldColumn.getMaxLength(),
oldColumn.getScale(), oldColumn.isNullable(), i-1+positionOffset,
oldColumn.getSortOrder(), oldColumn.getArraySize(),
oldColumn.getViewConstant(), oldColumn.isViewReferenced(),
oldColumn.getExpressionStr(), oldColumn.isRowTimestamp(),
oldColumn.isDynamic());
+ public void coerceBytes(ImmutableBytesWritable ptr, Object o, PDataType
actualType, Integer actualMaxLength,
{color:red}-1 core tests{color}. The patch failed these unit tests:
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.end2end.AlterTableIT
./phoenix-core/target/failsafe-reports/TEST-[ViewIndexIT_isNamespaceMapped=false]
Test results:
https://builds.apache.org/job/PreCommit-PHOENIX-Build/635//testReport/
Release audit warnings:
https://builds.apache.org/job/PreCommit-PHOENIX-Build/635//artifact/patchprocess/patchReleaseAuditWarnings.txt
Javadoc warnings:
https://builds.apache.org/job/PreCommit-PHOENIX-Build/635//artifact/patchprocess/patchJavadocWarnings.txt
Console output:
https://builds.apache.org/job/PreCommit-PHOENIX-Build/635//console
This message is automatically generated.
> Support declaration of DEFAULT in CREATE statement
> --------------------------------------------------
>
> Key: PHOENIX-476
> URL: https://issues.apache.org/jira/browse/PHOENIX-476
> Project: Phoenix
> Issue Type: Task
> Affects Versions: 3.0-Release
> Reporter: James Taylor
> Assignee: Kevin Liew
> Labels: enhancement
> Fix For: 4.9.0
>
> Attachments: PHOENIX-476.10.patch, PHOENIX-476.11.patch,
> PHOENIX-476.2.patch, PHOENIX-476.3.patch, PHOENIX-476.4.patch,
> PHOENIX-476.5.patch, PHOENIX-476.6.patch, PHOENIX-476.7.patch,
> PHOENIX-476.8.patch, PHOENIX-476.9.patch, PHOENIX-476.patch
>
>
> Support the declaration of a default value in the CREATE TABLE/VIEW statement
> like this:
> CREATE TABLE Persons (
> Pid int NOT NULL PRIMARY KEY,
> LastName varchar(255) NOT NULL,
> FirstName varchar(255),
> Address varchar(255),
> City varchar(255) DEFAULT 'Sandnes'
> )
> To implement this, we'd need to:
> 1. add a new DEFAULT_VALUE key value column in SYSTEM.TABLE and pass through
> the value when the table is created (in MetaDataClient).
> 2. always set NULLABLE to ResultSetMetaData.columnNoNulls if a default value
> is present, since the column will never be null.
> 3. add a getDefaultValue() accessor in PColumn
> 4. for a row key column, during UPSERT use the default value if no value was
> specified for that column. This could be done in the PTableImpl.newKey method.
> 5. for a key value column with a default value, we can get away without
> incurring any storage cost. Although a little bit of extra effort than if we
> persisted the default value on an UPSERT for key value columns, this approach
> has the benefit of not incurring any storage cost for a default value.
> * serialize any default value into KeyValueColumnExpression
> * in the evaluate method of KeyValueColumnExpression, conditionally use
> the default value if the column value is not present. If doing partial
> evaluation, you should not yet return the default value, as we may not have
> encountered the the KeyValue for the column yet (since a filter evaluates
> each time it sees each KeyValue, and there may be more than one KeyValue
> referenced in the expression). Partial evaluation is determined by calling
> Tuple.isImmutable(), where false means it is NOT doing partial evaluation,
> while true means it is.
> * modify EvaluateOnCompletionVisitor by adding a visitor method for
> RowKeyColumnExpression and KeyValueColumnExpression to set
> evaluateOnCompletion to true if they have a default value specified. This
> will cause filter evaluation to execute one final time after all KeyValues
> for a row have been seen, since it's at this time we know we should use the
> default value.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
