db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel John Debrunner (JIRA)" <derby-...@db.apache.org>
Subject [jira] Closed: (DERBY-738) Initialize parameters within activation without using generated code.
Date Tue, 11 Jul 2006 23:39:32 GMT
     [ http://issues.apache.org/jira/browse/DERBY-738?page=all ]
     
Daniel John Debrunner closed DERBY-738:
---------------------------------------


> Initialize parameters within activation without using generated code.
> ---------------------------------------------------------------------
>
>          Key: DERBY-738
>          URL: http://issues.apache.org/jira/browse/DERBY-738
>      Project: Derby
>         Type: Sub-task

>   Components: SQL
>     Reporter: Daniel John Debrunner
>     Assignee: Daniel John Debrunner
>     Priority: Minor
>      Fix For: 10.2.0.0

>
> For each parameter in a query the following code is generated, e.g. for the 23rd parameter
INT parameter.
> this.pvs.setStorableDataValue(
>     this.getDataValueFactory().getNullInteger(),
>     22, // parameter number
>     4, // Types.INTEGER
>      "java.lang.Integer");
> Apart being a significant amount of code per parameter , each of these will result in
a new class pool entry for:
>  - each parameter number (beyond 5)
>  - each unique Types.XXX value (beyond 5)
>  -  each unique class name for a type
> (integer constants -1 through 5 are special cased as instructions in the JVM bytecode
and do not require constant pool entries)
> This code is generated in the post constructor method of the generated class and its
purpose is to allocate a holder DataValueDescriptor of the correct type to the ParameterValueSet
for the statement. These are the parameters that will be directly set by the JDBC application.
> This code is generated by the method ParameterNode.generateHolder();
> The actual instanceof the ParameterValueSet is generated with a single call, by the generated
code passing in the number of parameters to BaseActivation.setParameterValueSet. This then
generates the structure for the parameters but does not create the DataValueDescriptors since
the types are not known.
> The fix is to use the type definitions stored in the associated language PreparedStatement
(prepared plan) DataTypeDescriptor[] to generate the null values and initalize the parameters.
> I'm looking at replacing the ParameterValueSet.setStorableDataValue with an initialize
method like:
> 	public void initialize(DataTypeDescriptor[] types)
> 	{
> 		for (int i = 0; i < parms.length; i++)
> 		{
> 			DataTypeDescriptor dtd = types[i];
> 			
> 			parms[i].initialize(dtd.getNull(),
> 					dtd.getJDBCTypeId(),
>                                         dtd.getTypeId().getCorrespondingJavaTypeName());
> 		}
> 	}
> With this, no code is required in the postConstructor() for a parameter. The initialize
method is called when
> the activation is linked to its prepared statement.. With my prototype the generated
code size for the DERBY-732 query dropped from around 70k to 60k. Of course this does not
fix DERBY-732, since it is not reducing code in the where clause method.
>     
>  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


Mime
View raw message