Tom,
> In a brand new product, the argument that says your new
> DatabasePlatform should be called SQLAnywherePlatform and the other
> platform should be renamed is a strong one. We are, however, dealing
> with a product that has already shipped a number of versions. As a
> result, people may be using the existing SQLAnywherePlatform, so, from
> a backward compatibility point of view, we cannot rename the existing
> SQLAnywherePlatform unless we think the new platform will provide
> better support for all SQLAnywherePlatform users. (Those using the
> driver that shipped with SQLAnywhere and those using JConnect) That
> is why I keep asking about JConnect. From an ease of use point of
> view, the ideal situation is that a user of SQLAnywhere uses
> SQLAnywherePlatform and it works whether the driver they are using is
> the one that ships with SQLAnywhere or JConnect.
>
> I will appologize in advance, if I should have ascertained the answer
> to the following question from earlier in the email thread, but I have
> not been able to, so I will ask it explicitly. Is the reason we need
> separate platforms for the shipped driver and the JConnect driver
> technical, or is it philosophical? If it is technical, can you
> provide an example of a technical issue with the coding to the
> DatabasePlatform that must be done differently for the shipped driver
> vs. the JConnect driver?
>
> I realize this is a bit of a frustrating question to have to answer,
> but as a product that has been in use for many years, backwards
> compatibility is a very key issue. As you mention, because of the
> kind of support you are providing, the platform you have written would
> ideally be called SQLAnywherePlatform. I just want to explore ways to
> make that possible and maintain backward compatibillity.
It is both, technically and philosophical. See, you already have a
SQLAnyWherePlatform and it seems nobody complained about it. My decision
to write a new one was purely philosophical: I actually never tried out
your existing platform due to the sole knowledge if its internal beeing
wrong by definition (since it cannot be technically correct to derive
from SybasePlatform).
Understanding this history, you will understand that there is no
difference in beeing a technical or philosophical question: My platform
solely exists due to philosophical reasons, so there cannot be any
technical reason. But if you mix in jConnect stuff in another way than I
proposed (using a separate inner class of SQLAnywherePlatform) then you
again have a unclean platform again (from a philosophical view) and
actually are where we started: You can just keep the old platform, the
new one will be nothing better (actually my work is lost then)!
But in addition, there might arise technical reasons:
(a) As you know, jConnect produces far more crashes in the
entity-persistence-tests. So you need more fixes. Since the platform
cannot find out what driver is running currently without losing some
quantum of time with each single query, jConnect fixes will potentially
lose time even when the platform is running on iAnywhere. And that is a
thing that makes me headache: I don't want to provide a platform that is
perfect and then put things into just because of some doubtful backwards
compatiblity -- if that compatibility fixes create measurable
performance drawbacks. :-(
(b) You say that people are using SQLAnyWherePlatform already. Stop, you
might have the wrong view angle. I am contributing SQLAnywherePlatform
solely to GlassFish. GlassFish doesn't describe how to use the platform
explicitely. The only point where GlassFish lets the user see the
platform is when adding a JDBC Connection Pool. Ever tried it out? It
tells you MySQL, Sybase, and others -- but not "SQLAnywherePlatform"
(exactly that words are what we are talking about)!. Even the Vendor
Mapping File in GlassFish currently does not provide any information
about SQLAnywhere. Actually at least MY GlassFish instance (which is a
default installation) doesn't tell me anything about SQLAnywhere but
choses the classname "SQLAnyhwerePlatform" solely by querying for driver
name and mapping file. So a GlassFish user cannot be a user of your old
platform actually. So what impact are you talking about? There cannot be
any GlassFish user that has chosen SQLAnyhwerePlatform (the name, not
the feature) by intention (or nobody told me how to do it in GlassFish).
(c) What problem should an existing user have reading the release note
"If you are using jConnect with SQLAnyhwere, then go into your config
and change from SQLAnyWhere to JConnectSQLAnywhere"? That fix is done in
one minute and we all would have a clean system.
(d) As Lance and I agreed upon, it might be possible to put the jConnect
fixes into a subclass of my platform so my platform will learn to be
jConnect compliant without cluttering or losing performance. But this
only works, if it is possible to ask for the actual driver name ONCE at
boot time (in fact, I don't know if this is possible). If I need to ask
for the driver name with each query, the performance loss would not
acceptable.
Have Fun
Markus