db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mike Matrigali (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DERBY-6003) Create row templates outside of the generated code
Date Fri, 30 Nov 2012 17:55:58 GMT

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

Mike Matrigali commented on DERBY-6003:

Changes look good to me.

With respect to downgrade issue, I wonder if it is necesary.  I don't understand the performance
impact, but a little concerned that we are penalizing a lot of users that will not see the
At least in the cases where an apache release exists that fixes the bugs with usual handling
of upgrade and downgrade, should we still disable the trigger performance because user may
downgrade to a release known release with more bugs, ie. say db version is 10.8 and latest
10.8 release has all fixes.

Also to understand the range of your changes, do you plan on backporting the downgrade changes,
or will these just be in 10.10 software and above?

I understand it helps with the tests.  In general I think we expect to people to at least
be able to software upgrade to the latest bug fix release on a given branch.  As we decided
it was reasonable if version X.1 could not boot because of bug that user could could use X.2.
Now if there are no available apache releases for a given version your fix seems like an excellent
help to those users stuck at that 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:
>            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

View raw message