db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Knut Anders Hatlen (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (DERBY-6003) Create row templates outside of the generated code
Date Thu, 06 Dec 2012 14:07:10 GMT

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

Knut Anders Hatlen updated DERBY-6003:

    Attachment: d6003-3c-downgrade-with-stored-proc.diff

I wasn't quite happy with the approach in the 3b patch either, as I didn't like having to
expose the clearSPSPlans() method in the DataDictionary interface just for the tests.

So I went back and tried to find out why the new SYSCS_INVALIDATE_STORED_STATEMENTS procedure
didn't do the trick. The procedure calls SPSDescriptor.makeInvalid() on all the SPSs in SYS.SYSSTATEMENTS.
That method sets the VALID to false in the system table, but the actual plan is left there.

The procedure could potentially help with more bugs if it also cleared the plan. The statement
is going to be recompiled on the next execution anyways, so there's no value in keeping the
plan in the system table.

The attached patch d6003-3c-downgrade-with-stored-proc.diff implements that approach and makes
SPSDescriptor.makeInvalid() change both the VALID column and the CONSTANTSTATE column (which
holds the plan). It adds the same workaround to the upgrade tests as the 3b patch, only that
it calls SYSCS_INVALIDATE_STORED_STATEMENT instead of DataDictionary.clearSPSPlans().

The patch makes the upgrade tests run cleanly in combination with the 4a patch. It has the
following advantages over the 3b patch:

- No new interface methods in the DataDictionary

- It makes SYSCS_INVALIDATE_STORED_STATEMENT useful for a larger class of bugs
> Create row templates outside of the generated code
> --------------------------------------------------
>                 Key: DERBY-6003
>                 URL: https://issues.apache.org/jira/browse/DERBY-6003
>             Project: Derby
>          Issue Type: Improvement
>          Components: SQL
>    Affects Versions:
>            Reporter: Knut Anders Hatlen
>            Assignee: Knut Anders Hatlen
>            Priority: Minor
>         Attachments: d6003-1a-cleanup.diff, d6003-2a-unused-field.diff, d6003-3a-safe-downgrade.diff,
d6003-3b-downgrade-workaround-in-tests.diff, d6003-3c-downgrade-with-stored-proc.diff, d6003-4a-scanresultset.diff
> The constructors for many of the result set classes take GeneratedMethod parameters that
create row templates (an ExecRow of a certain size and column types, each column initialized
to an SQL null value).
> As an alternative, the compiler could produce an ExecRow instance and put it into the
savedObjects field of GenericPreparedStatement, and the constructors could take parameter
that points to the object in savedObjects. Where the result sets currently invoke the generated
method to produce a fresh template, they could instead clone the saved object.
> Advantages with the suggested approach would be:
> - Reduce the size of the code generator, which should reduce total code complexity.
> - Reduce the amount of generated code, which makes it easier for tools (profilers, static
code analyzers, IDEs) to map executable code to source code.
> - Reduce the actual number of generated methods, which makes it less likely that queries
need to use reflection to invoke the remaining generated methods (there's a switchover from
DirectCall to ReflectCall when the number of generated methods exceeds 10).

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