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, 13 Dec 2012 10:40:15 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-6a-index-to-base-row.diff

Attaching d6003-6a-index-to-base-row.diff which makes IndexRowToBaseRowResultSet use an ExecRowBuilder
instead of a generated method to create the row template used in the scan.

This was the last remaining caller of ResultColumnList.generateHolder(), so the patch also
removes the code that creates byte code for allocating row templates.

IndexRowToBaseRowResultSet's invocation of generateHolder() used some extra logic to skip
columns already fetched from the index. The patch merges this logic into the buildRowTemplate()
method, which now takes an extra parameter to tell whether or not to skip certain columns.

All regression tests ran cleanly with the patch.

Patch details:

- java/engine/org/apache/derby/impl/sql/compile/ResultColumnList.java

Remove the generateHolder() and generateHolderMethod() methods.

Move the missing logic for skipping index columns into the buildRowTemplate() method, and
add extra parameter.

Add shorthand variant of buildRowTemplate() that takes no arguments, since most callers don't
have anything to pass in.

- java/engine/org/apache/derby/impl/sql/compile/IndexToBaseRowNode.java

Push a reference to an ExecRowBuilder instead of a generated method as argument to the result
set creation method.

- java/engine/org/apache/derby/impl/sql/execute/IndexRowToBaseRowResultSet.java

Use the saved ExecRowBuilder instead of a generated method when creating the row template
in the constructor.

- java/engine/org/apache/derby/iapi/sql/execute/ResultSetFactory.java
- java/engine/org/apache/derby/impl/sql/execute/GenericResultSetFactory.java

Change method signatures to take saved object index instead of generated method.

- java/engine/org/apache/derby/impl/sql/compile/DistinctNode.java
- java/engine/org/apache/derby/impl/sql/compile/FromBaseTable.java
- java/engine/org/apache/derby/impl/sql/compile/FromVTI.java
- java/engine/org/apache/derby/impl/sql/compile/GroupByNode.java
- java/engine/org/apache/derby/impl/sql/compile/OrderByList.java
- java/engine/org/apache/derby/impl/sql/compile/WindowResultSetNode.java

Update calls to ResultColumnList.buildRowTemplate() with the correct number of arguments after
the signature change to allow skipping index columns.
                
> 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,
d6003-3b-downgrade-workaround-in-tests.diff, d6003-3c-downgrade-with-stored-proc.diff, d6003-4a-scanresultset.diff,
d6003-5a-sort-vti-aggregate-window.diff, d6003-6a-index-to-base-row.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