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 21:37:11 GMT
Another great verb from Rick that captures the situation perfectly... :)

David

Rick Hillegas wrote:
> 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