db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Van Couvering <David.Vancouver...@Sun.COM>
Subject Re: [jira] Updated: (DERBY-289) Enable code sharing between Derby client and engine
Date Wed, 16 Nov 2005 04:38:23 GMT
Hi, Dan.  I was taken off guard by the incompatibility of message 
changes, too.  However, note that you will have to do something similar 
every time you add a new parameter to a method, and it's likely that 
over time our code will be littered with conditional logic like this.

Your suggested solution to use a composite message id doesn't handle the 
fact that the old message id takes no arguments whereas the new one 
takes one argument.  How would that be solved?

At any rate, this is a one-off solution for a more general problem.

If anybody has a brilliant idea for a design pattern that makes building 
forward-compatible code more readable and less complex, please send 
those cards and letters out.

I am personally wondering if there is a way to allow people to configure 
Derby to use a specialized classloader ala what Kathey is doing.  Maybe 
something where you can provide a property to the connection URL that 
specifies the directory where derby jars can be found.  This could 
signal the DataSource to load all its dependent classes using a 
specialized classloader.  A gleam in my eye at this point, but I'll look 
into this further unless someone shows me it's just not worth my time. 
If we could do something like that we could avoid this whole forward 
(and backward) compatibility issue altogether...


Daniel John Debrunner wrote:
> Deepa Remesh wrote:
>>I changed client driver to use the new message:
>>		if (!parameterSet_[i] && !parameterRegistered_[i]) {
>>			CommonInfo cInfo = new CommonInfo();
>>		   	if(cInfo.hasFeature(CommonFeatures.SQLSTATE_07000_NEW))
>>		    		throw new SqlException2(agent_.logWriter_,
>>SQLState.LANG_MISSING_PARMS2, new Integer (i));
>>		    	else
>>		      		throw new SqlException2(agent_.logWriter_,
>>		}
> Hmmmm, I think you are correct Deepa in your approach to this, but the
> shared code setup sure does result in some painful code. When I
> discussed versioning, I wasn't assuming it would go down to the
> individual message level.
> I think, at least for messages, the actual shared code could provide
> much of the support for changing messages. Doing this work up-front
> would result in clean code, without version checking. Couple of ideas I
> had after thinking about this are:
>   - Have the new message identifier also include the old, something
> like: 07000.S>07000, so that if the new identifier is not available the
> message code looks for the old identifier.
>   - Take advantage of the fact that Java can load multiple resource
> files with the same name to merge old and new resources.
> Dan.

View raw message