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.
