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 Mon, 03 Dec 2012 16:03:58 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-4a-scanresultset.diff

Attaching d6003-4a-scanresultset.diff which removes the generated
methods that create row templates for the ScanResultSet tree. It
currently depends on the 3a patch in order to make the upgrade tests

There still are other result set classes that use generated methods to
produce row templates, so the code that generates the code is not
removed in this patch. I'll post other patches later to fix the rest
of the result set tree and remove the generated code.

This patch adds a new class, called ExecRowBuilder, which can be used
to produce and reset candidate rows used by the scan result sets. Its
build() method creates an instance of the correct sub-type of ExecRow
with SQL null values in the columns used by the scan. This is what was
previously done in the generated constructor for the activation. Its
reset() method replaces the existing values in the row with fresh
instances that represent SQL null of the correct type, which is the
same as the generated methods previously did.

Instead of passing a reference to the generated method into the
ScanResultSet constructor, the compiler now stores an ExecRowBuilder
in GenericPreparedStatement.savedObjects and passes the array index as
an argument to the constructor.


- java/engine/org/apache/derby/iapi/sql/execute/ExecRowBuilder.java

New class, as described above.

- java/engine/org/apache/derby/iapi/types/DataTypeDescriptor.java

As mentioned in an earlier comment, DTD's deserialization wouldn't
fully restore the state of the original instance if it represented a
user-defined type. Fixed by using TypeId.getUserDefinedTypeId()
instead of TypeId.getBuiltInTypeId() if the type is user-defined.

This was needed in order to get ExecRowBuilder to deserialize
successfully when the query accessed UDTs.

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

Added a method buildRowTemplate() that creates an ExecRowBuilder of
the right shape. The logic is essentially the same as in the existing
ResultColumnList.generateHolder() method, except that generateHolder()
produces a byte-code representation of how to produce the row, and
buildRowTemplate() produces a Java data structure holding the same

Factored out shared logic from generateHolder() and buildRowTemplate()
into newRowLocationTemplate().

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

Use RCL.buildRowTemplate() instead of RCL.generateHolder() when
creating constructor arguments for a sub-class of ScanResultSet.

- java/engine/org/apache/derby/iapi/sql/compile/JoinStrategy.java
- java/engine/org/apache/derby/impl/sql/compile/BaseJoinStrategy.java
- java/engine/org/apache/derby/impl/sql/compile/HashJoinStrategy.java
- java/engine/org/apache/derby/impl/sql/compile/NestedLoopJoinStrategy.java

Changed signatures to allow passing array index into GPS.savedObjects
instead of generated method as scan parameter.

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

Create the candidate row using the passed-in ExecRowBuilder, and also
use the ExecRowBuilder to reset the candidate row.

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

Changed signature of constructor to index into GPS.savedObjects
instead of generated method. Use the ExecRowBuilder to reset the
candidate row.

- java/engine/org/apache/derby/iapi/sql/execute/ResultSetFactory.java
- java/engine/org/apache/derby/impl/sql/execute/GenericResultSetFactory.java
- java/engine/org/apache/derby/impl/sql/execute/BulkTableScanResultSet.java
- java/engine/org/apache/derby/impl/sql/execute/DependentResultSet.java
- java/engine/org/apache/derby/impl/sql/execute/DistinctScanResultSet.java
- java/engine/org/apache/derby/impl/sql/execute/LastIndexKeyResultSet.java
- java/engine/org/apache/derby/impl/sql/execute/MultiProbeTableScanResultSet.java

More signature changes to allow passing the GPS.savedObjects index
instead of the generated method.

- java/engine/org/apache/derby/impl/sql/compile/InsertNode.java
- java/engine/org/apache/derby/impl/sql/execute/InsertResultSet.java

Bulk insert creates a BulkTableScanResultSet at run-time and needs a
way to pass a row template to the scan. Previously, it did this by
wrapping a row instance in a class that implemented the
GeneratedMethod interface, although it didn't actually represent a
generated method. Now, since BulkTableScanResultSet expects an index
into GPS.savedObjects, we instead save an ExecRowBuilder instance when
compiling the bulk insert, and let InsertResultSet pass the array
index to getBulkTableScanResultSet().

InsertNode also needed a fix in requestBulkInsert(). It does some bind
logic in the optimize phase (legitimately, because of DERBY-4789), but
forgets to update the bulkInsert field which is usually set during
bind. We now set bulkInsert to true also when this method is called,
so that we can use the field in the code generation phase.

- java/engine/org/apache/derby/impl/sql/compile/DeleteNode.java
- java/engine/org/apache/derby/impl/sql/compile/UpdateNode.java
- java/engine/org/apache/derby/impl/sql/execute/DeleteConstantAction.java
- java/engine/org/apache/derby/impl/sql/execute/GenericConstantActionFactory.java
- java/engine/org/apache/derby/impl/sql/execute/InsertConstantAction.java
- java/engine/org/apache/derby/impl/sql/execute/UpdatableVTIConstantAction.java
- java/engine/org/apache/derby/impl/sql/execute/WriteCursorConstantAction.java

Since InsertResultSet now gets its row template added to the plan at
compile-time, remove the logic to add it to and get it from the
constant action. This logic was also present for update and delete,
although it was only used in bulk insert. Remove for update and delete
> 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