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 20:20:04 GMT
Oh, right, I didn't track that one. Over time these versioned overloads 
and if-blocks will calcify the code..

-Rick

David W. Van Couvering wrote:

> 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.
>
> David
>
> 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_,
>>>>> SQLState.LANG_MISSING_PARMS);
>>>>>         }
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> 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.
>>>>
>>


Mime
View raw message