db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David W. 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 18:57:10 GMT
I think the lint tool sounds great!  That said, I don't get how it 
solves the forward-compabitility code crud as Deepa's code exemplifies, 
where you have to check for the feature id to make sure you can use the 
new message id before.


Rick Hillegas wrote:
> 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 
> tool.
> Cheers,
> -Rick
> 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