[
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-2a-unused-field.diff
To fix the above mentioned deserialization problem in DataTypeDescriptor, I
think we need to make DataTypeDescriptor.readExternal() call
TypeId.getUserDefinedTypeId() instead of TypeId.getBuiltInTypeId() if it's a
user-defined type.
The getUserDefinedTypeId() takes a boolean parameter called
delimitedIdentifier. I don't know what's the right value to pass in. But
looking closer at it, it looks like the value is never used, and all callers
pass in false. So to make the final patch simpler, I'm attaching another
cleanup patch (d6003-2a-unused-field.diff) that removes this dead code. That
should be an improvement regardless of how we end up fixing the rest of the
issue.
All tests ran cleanly with the 2a patch.
> 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
>
>
> 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
