db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick Hillegas <Richard.Hille...@Sun.COM>
Subject Re: [jira] Updated: (DERBY-289) Enable code sharing between Derby client and engine
Date Wed, 16 Nov 2005 14:53:03 GMT
Perhaps we could impose the following rules and enforce the first with a 
lint tool, either at release time or as part of a comprehensive weekly test:

1) If you change the number of args in a message, then you need to 
create a new message id.
2) At the same time, you need to replace all references to the old 
message id with references to the new id.

It's worth pointing out that this is not a new defect introduced by code 
sharing. This is a problem which plagues many message resolution 
systems--because they rely on weakly typed varargs.

I'm already hoping to build a 10.2 lint tool for messages. My first use 
of this tool was going to be to identify messages which haven't been 
translated yet and the locales which need translations. This lint tool 
could also do the following: Raise an error if the tool finds a message 
whose argument counts have changed between releases.

If this seems useful, I can log an enhancment request to track this lint 


David Van Couvering wrote:

> 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...
> David
> 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