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: VOTE: Principles of sharing code
Date Thu, 27 Oct 2005 23:47:42 GMT

Kathey Marsden wrote:
> I like this wording better than the other and wouldn't veto it, but I am
> fully willing to disclose that I couldn't offer it my binding +1 either
> because I think, to use Naka's term, it is a trap.  I don't really
> believe that there will be no user impact but will hold you to it.

OK, fair enough.  I appreciate your rigor and concern.

>  I woke up this morning and realized I don't know how I would fix a bug
> in shared code with mixed jars, because the class in the other jar would
> mask my fix.  I'm sure you have something planned for that and you don't
> have to explain it to me now, but  when you submit your patch, the very
> first thing  I'll do is 1) try to fix an imaginary customer bug and put
> the unchanged  jar first  2) try to add a parameter to a message  with
> no impact to the old jars regardless of classpath.  Those should both be
> doable  with what you have planned  right?

Yes, they should be.  Let me try to answer them here and see what you think.

Scenario 1 - Fixing a Bug

If I have it right the issue of "masking" comes up only when you have a 
mixed version environment.  Let's say the user is running with the 10.2 
embedded driver and the 10.3 client driver.  Hopefully the user tells us 
"I'm using both 10.2 and 10.3."  Then we would fix the bug in both the 
10.2 and 10.3 common code.

If for some reason the user doesn't tell us this, we may fix the bug in 
the wrong version the first time, but after getting more info from the 
customer it will be clear that the bugfix should be ported to the other 

We could have a policy that a common bug fix should be ported to all 
releases currently available and supported, but that seems like overkill 
and against the policy of "scratch your own itch" -- a bug should be 
fixed in the versions that matter to the user who has the bug.

So I would argue when you do your test, you should make the fix in both 
versions of the common code and you should see no problem.

Scenario 2 - Adding a parameter to a message

This is a great example, and I'm glad you brought it up, I hadn't 
thought of it.  You've motivated me to work through as many use cases as 
possible and document these on the Wiki page as part of our "hashing 
out" of how to do common code.

Anyway, here's how I would do it.  This probably isn't obvious, but 
message strings should be viewed as interfaces that should follow the 
same compatibility rules as Java methods.  I'll add this note on the 
Wiki page.   If you change the "signature" of a message, this is an 
incompatible change, and you should create a new message rather than 
modify the existing message.  Since it's likely the SQL State is the 
same for the old and new messages, you need to deal with this.  Let's 
say the old message id is "XJ786.S".  The new message id should be 
something like "XJ786.S.2".

To support forward-compatibility, you need to add a feature id like 
CommonInfo.SQLSTATE_MSGID_XJ786_2, and the code can check to see if the 
feature exists.  If it doesn't, it uses the old message.

Alternately, the messaging infrastructure knows how to build a "default 
message" if the message id can't be found, and you can just take 
advantage of that.  But this default message is pretty ugly and IMHO 
should be avoided.


> Kathey

View raw message