[
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-3a-safe-downgrade.diff
Attaching d6003-3a-safe-downgrade.diff which makes the suggested changes to
allow safe downgrade after the format of stored plans has changed.
Details:
SPSDescriptor: Added a method that checks if it is safe to store the plan. It
is considered safe if the dictionary version is 10.9 or higher, since all
released versions on the 10.9 branch have the fixes for DERBY-3870 and
DERBY-4835.
SYSSTATEMENTSRowFactory: When creating a row to store in SYSSTATEMENTS, use the
new method in SPSDescriptor to check if it's safe to store the plan. If it is
not, return a row that has the VALID column set to false and the CONSTANTSTATE
column (which is where the plan is stored) to null. Changing those two columns
is what the clearSPSPlans() method does too when the version has changed.
DataDictionaryImpl: When a new database is created, set the dictionary version
before creating the system tables. Otherwise, the version check in
SPSDescriptor will fail with a NullPointerException when the SYSSTATEMENTS
table is created.
BasicSetup: Removed the workarounds for DERBY-4835, DERBY-5105, DERBY-5263 and
DERBY-5289, as this fix makes downgrade successful for some test cases that
used to fail.
> 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
