db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rick Hillegas (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (DERBY-672) Re-enable user defined aggregates
Date Mon, 22 Oct 2012 18:28:13 GMT

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

Rick Hillegas updated DERBY-672:

    Attachment: derby-672-20-aa-exactBounds.diff

Attaching derby-672-20-aa-exactBounds.diff. This patch tightens up the bounds checking on
the input and return types of user-defined aggregates. Committed at subversion revision 1400984.

When I simplified bounds checking for input and return types, I lost the ability to catch
some user mistakes at compile time. So for instance, given the following UDA:

    create derby aggregate bigintMode_16 for bigint
    external name 'org.apache.derbyTesting.functionTests.tests.lang.GenericMode$IntMode'

...the following statement would fail at run time when the user code tried to cast a Long
to an Integer:

    select bigintMode_16( b ) from bigintMode_16_mode_inputs

The solution was to revive the tricky code which I deprecated in patch derby-672-10-af-typeBounds.diff
and to use that tricky code alongside the simpler bounds checking introduced by that patch.
The tricky code catches the above mismatch at bind() time rather than failing at run time.
I am not pleased by the complexity of the tricky code but I think it is better to catch these
kinds of errors when the statement is compiled.

Touches the following files:


M       java/engine/org/apache/derby/iapi/services/loader/Java5ClassInspector.java
M       java/engine/org/apache/derby/iapi/services/loader/ClassInspector.java

Re-introduce the tricky code.


M       java/engine/org/apache/derby/impl/sql/compile/UserAggregateDefinition.java

Wire the tricky code back into bind-time type resolution.


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

While experimenting, I changed the name of the GenericMode type variable from V to B. This
helps to clearly disambiguate it from the V type variable of the Aggregator class itself.
It's a cosmetic change which I think may be useful in the future if we need to keep improving
bounds checking for UDAs.


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

Additional tests.

> Re-enable user defined aggregates
> ---------------------------------
>                 Key: DERBY-672
>                 URL: https://issues.apache.org/jira/browse/DERBY-672
>             Project: Derby
>          Issue Type: Improvement
>          Components: SQL
>            Reporter: Rick Hillegas
>            Assignee: Rick Hillegas
>         Attachments: derby-672-01-aa-ddl.diff, derby-672-02-ac-nonDistinct.diff, derby-672-03-aa-distinct.diff,
derby-672-03-ab-distinct.diff, derby-672-04-aa-fixJSR169test.diff, derby-672-05-aa-java7testOrderProblem.diff,
derby-672-06-aa-grantRevoke.diff, derby-672-07-aa-fixJSR169again.diff, derby-672-08-aa-fixJSR169yetAgain.diff,
derby-672-09-ab-udtAggregates.diff, derby-672-10-af-typeBounds.diff, derby-672-11-aa-tests.diff,
derby-672-11-ab-tests.diff, derby-672-12-aa-implicitCasts.diff, derby-672-13-aa-differentReturnType.diff,
derby-672-14-aa-collations.diff, derby-672-15-aa-setCollation.diff, derby-672-16-aa-forbidInGroupBy.diff,
derby-672-17-aa-moreTests.diff, derby-672-18-aa-udaInJar.diff, derby-672-19-aa-precisionChecks.diff,
derby-672-20-aa-exactBounds.diff, UserDefinedAggregates.html, UserDefinedAggregates.html,
> Nicolas Dufour in an email thread titled "functions and list" started on November 2,
2005 requests the ability to create user defined aggregates.
> This functionality used to be in Cloudscape. It was disabled presumably because it was
considered non-standard. However, most of the machinery needed for this feature is still in
the code. We should re-enable user defined aggregates after we agree on acceptable syntax.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

View raw message