jdbc4.0 implementation plan

[V Narayanan <V....@Sun.COM>]

1) build a stub foundation into which we can plug additional features 
incrementally and in parallel

	steps in doing this

	a) create a seperate package org.apache.derby.impl.jdbc4

	b) extend classes in the org.apache.derby.impl.jdbc package

	c) provide implementation for methods in the JDBC4.0 spec that
	   are not currently present in the JDBC layer of derby.

	d) the implementations would actually be
            throws util.notImplemented();

so for example we have a EmbedBlob.java inside org.apache.impl.jdbc class

let us assume that there are two additional functions supported since 
the JDBC4.0 implementation namely func1 and func2 so what we would 
basically be doing would be

	inside the package org.apache.derby.impl.jdbc4 package

	EmbedBlob.java

	final class EmbedBlob extends org.apache.derby.impl.jdbc.EmbedBlob
	{
		public <return_type> func1(<parameters>)
		{
		    	throw Util.notImplemented();
		}
        		public <return_type> func2(<parameters>)
		{
     			throw Util.notImplemented();
		}
	}


Queries
-------

1)	we observed that in the current build we have support for 		JDBC2.0 
and JDBC3.0 within the same package viz. org.apache.derby.impl.jdbc (e.g 
EmbedPreparedStatement30 extends EmbedPreparedStatement20 inside the 
same package).

	we had decided on a seperate package because we thought this would 
result in a cleaner build. would this be the best approach or should it 
be part of the same package?

thanx
V.Narayanan

Re: jdbc4.0 implementation plan

[Rick Hillegas <Ri...@Sun.COM>]

Hi Dan,

Thanks for your comments on Narayanan's proposal:

1) You want to trim Derby footprint by not creating unnecessary classes.

2) You want to be able to use package protection across the jdbc 
implementations.

I think that (1) is a generally good idea although the code can be 
muddled by pressing it too far. In this case I think it makes sense 
since you can gather the extension methods into tidy, well-commented 
code blocks.

Issue (2) is also compelling.

Cheers,
-Rick


Daniel John Debrunner wrote:

>V Narayanan wrote:
>
>  
>
>>1) build a stub foundation into which we can plug additional features
>>incrementally and in parallel
>>
>>    steps in doing this
>>
>>
>>    b) extend classes in the org.apache.derby.impl.jdbc package
>>
>>    
>>
>
>The approach Derby has taken is to only have specific version classes if
>there is a real need. E.g. EmbedDatabaseMetaData is a single class
>supporting JSR169, JDBC2 and JDBC3. A real need occurs if the JDBC 4
>class has new methods that reference new Java types introduced in JDBC4.
>A new real need is probably if the method signature has generics.
>
>  
>
>>    c) provide implementation for methods in the JDBC4.0 spec that
>>       are not currently present in the JDBC layer of derby.
>>    
>>
>
>It's sometime useful to push the methods as far into the parent classes
>as possible, thus if a method is introduced in JDBC 4 that does not
>reference any new JDBC 4 classes, then it is safe to include it in the
>base class or the one for JDBC 2.0 or JDBC 3.0. This is helpful for the
>JDBC subsets for J2ME. This is because JSR 169 is a subset of JDBC 3.0
>thus needs some of the methods from JDBC 3.0. Assuming a similar
>subsetting of JDBC 4 in the future then pushing them up is helpful.
>
>Dan.
>
>
>
>
>
>  
>

Re: jdbc4.0 implementation plan

[Daniel John Debrunner <dj...@debrunners.com>]

V Narayanan wrote:

> 1) build a stub foundation into which we can plug additional features
> incrementally and in parallel
> 
>     steps in doing this
> 
> 
>     b) extend classes in the org.apache.derby.impl.jdbc package
> 

The approach Derby has taken is to only have specific version classes if
there is a real need. E.g. EmbedDatabaseMetaData is a single class
supporting JSR169, JDBC2 and JDBC3. A real need occurs if the JDBC 4
class has new methods that reference new Java types introduced in JDBC4.
A new real need is probably if the method signature has generics.

>     c) provide implementation for methods in the JDBC4.0 spec that
>        are not currently present in the JDBC layer of derby.

It's sometime useful to push the methods as far into the parent classes
as possible, thus if a method is introduced in JDBC 4 that does not
reference any new JDBC 4 classes, then it is safe to include it in the
base class or the one for JDBC 2.0 or JDBC 3.0. This is helpful for the
JDBC subsets for J2ME. This is because JSR 169 is a subset of JDBC 3.0
thus needs some of the methods from JDBC 3.0. Assuming a similar
subsetting of JDBC 4 in the future then pushing them up is helpful.

Dan.

Re: jdbc4.0 implementation plan

[Daniel John Debrunner <dj...@debrunners.com>]

V Narayanan wrote:

> Queries
> -------
> 
> 1)    we observed that in the current build we have support for        
> JDBC2.0 and JDBC3.0 within the same package viz.
> org.apache.derby.impl.jdbc (e.g EmbedPreparedStatement30 extends
> EmbedPreparedStatement20 inside the same package).
> 
>     we had decided on a seperate package because we thought this would
> result in a cleaner build. would this be the best approach or should it
>> be part of the same package?

Derby (as Cloudscape) used to have the different jdbc drivers in
different packages. The trouble with this approach is that is begins to
force implementation classes and methods to be public, so they can be
called from all drivers. Since these classes are returned to
applications, these methods can then be called by applications,
potentially leading to security issues. Keeping the classes in the same
package allows the members to be package protected which are a lot
easier to be protect from malicious use. I'm not saying Derby's perfect
in this area now, in fact I'm spending some time looking at these issues.

So I would recommend continuing the use of a single package, unless
there's a good reason for a separate one. The build system handles
separate builds in the same package, so that's not an issue.

Dan.