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
branch.
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.
David
Kathey
begin:vcard
fn:David W Van Couvering
n:Van Couvering;David W
org:Sun Microsystems, Inc.;Database Technology Group
email;internet:[EMAIL PROTECTED]
title:Senior Staff Software Engineer
tel;work:510-550-6819
tel;cell:510-684-7281
x-mozilla-html:TRUE
version:2.1
end:vcard
