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.
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
