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] [Commented] (DERBY-6003) Create row templates outside of the generated code
Date Mon, 03 Dec 2012 14:49:58 GMT

    [ https://issues.apache.org/jira/browse/DERBY-6003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13508772#comment-13508772
] 

Knut Anders Hatlen commented on DERBY-6003:
-------------------------------------------

Thanks for looking at the patch, Mike.

I was not planning to backport this change, only commit it to trunk. However, if there are
concerns that this fix may be to broad, I can always add workarounds to the upgrade tests
instead.

There are no official releases with the necessary fixes for 10.5, 10.6 or 10.7. Not for the
earlier branches either, but it doesn't appear to be a problem on those branches, probably
because DERBY-1107 was not introduced until 10.5. On 10.8 it was fixed in a maintenance release,
and 10.9 included the fixes in the first official release.
                
> 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: 10.10.0.0
>            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
>
>
> 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

Mime
View raw message