You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Rick Hillegas (JIRA)" <ji...@apache.org> on 2010/05/12 20:26:42 UTC

[jira] Updated: (DERBY-4651) Hidden assumptions in FromVTI.makeRestriction()

     [ https://issues.apache.org/jira/browse/DERBY-4651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Rick Hillegas updated DERBY-4651:
---------------------------------

    Attachment: derby-4651-01-aa-verificationTest.diff

Attaching derby-4651-01-aa-verificationTest.diff. This patch adds a test case to track the fact that the VTI's qualification logic isn't short-circuited by queries whose WHERE clauses end in constant expressions. Committed at subversion revision 943605 and ported to the 10.6 branch at revision 943616.

I have not been able to figure out how to trigger the problem case raised by Knut. Right now Derby rejects the true and false literals. I have tried to replace them with simple expressions which are really constant, in the hope that the compiler would pre-compute the constant expressions and substitute them in the query tree. However, all I have succeeded in doing is forcing the compiler to not pass any restriction into the VTI.

This problem case raised by Knut may very well arise once we re-enable the true and false literals. We should write some defensive code around this situation before we re-enable the literals.

Touches the following files:

-------

M      java/testing/org/apache/derbyTesting/functionTests/tests/lang/IntegerArrayVTI.java

Beefs up the VTI with machinery to actually enforce the restriction that was pushed into the VTI and to report the number of rows which came out of the VTI.

-------

M      java/testing/org/apache/derbyTesting/functionTests/tests/lang/RestrictedVTITest.java

New test case to verify my simple attempts to create the problem situation reported by Knut.


> Hidden assumptions in FromVTI.makeRestriction()
> -----------------------------------------------
>
>                 Key: DERBY-4651
>                 URL: https://issues.apache.org/jira/browse/DERBY-4651
>             Project: Derby
>          Issue Type: Bug
>          Components: SQL
>    Affects Versions: 10.6.1.0
>            Reporter: Knut Anders Hatlen
>            Priority: Minor
>         Attachments: derby-4651-01-aa-verificationTest.diff
>
>
> FromVTI.makeRestriction() has this code to strip away Boolean constants from AND and OR expressions:
>             // strip off trailing vacuous constant if present
>             if ( andOperator.getRightOperand() instanceof BooleanConstantNode )
>             { return makeRestriction( andOperator.getLeftOperand(), columnNameMap ); }
> and
>             // strip off trailing vacuous constant if present
>             if ( orOperator.getRightOperand() instanceof BooleanConstantNode )
>             { return makeRestriction( orOperator.getLeftOperand(), columnNameMap ); }
> The code for AND will only work as expected if the right operand is TRUE. The code for OR only works correctly if the right operand is FALSE.
> I'm not sure if this can ever result in user-visible bugs, since Boolean constants are usually removed before we get to this point in the code. The predicate has probably been transformed to conjunctive normal form, in which Boolean constants in the right operand of an AndNode or an OrNode in fact is always TRUE or FALSE, respectively.
> I think this code either should be changed to work regardless of the value of the constant in the right operand, or the assumption that the predicate is on conjunctive normal form should be documented in the comments (and perhaps also checked in an assert statement).

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.