Hi Markus,
Appologies for the late reply. As I mentioned in a separate email to
you, I am currently on a critical path for another project.
Comments inline:
Markus KARG wrote:
>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)!
>
>
I am still missing one piece of understanding due to my limited
knowledge of SQLAnywhere. Since you are obviously quite a bit more
expert than I, perhaps you can give me a quick lesson. You talk about
mixing in the JConnect stuff. Can you give an example or two of how
your SQLAnywherePlatform would have to be implemented differently in
order to work with JConnect. Are there different types that should be
used? Are there methods that would have to be implemented differently?
I am just hoping to get a clearer view of how the JConnect stuff will
cause issues with the "cleanness" of your platform.
>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. :-(
>
>
Are we talking about time related to checking what driver is running?
If so, I agree. We must determine what DatabasePlatform to use at
bootstrap time and not have any need to check again (and definitely not
do a driver check with each call)
I definitely agree we need to avoid performance drawbacks. As I
mentioned above, as a SQLAnywhere amateur, I am hoping that someone can
provide me with an example of how the SQLAnywherePlatform would perform
worse if JConnect support was included in the current platform. (e.g.
show me an example of a method that would be different for SQLAnywhere's
shipped driver versus JConnect)
>(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).
>
>
Although TopLink Essentials is a component of GlassFish, it is also the
reference implementation for the JPA specification. It can certainly be
used within GlassFish, but that can also be used with any container that
is capable of using JPA. In fact, it is shipped as the default JPA
implementation with a number of other containers including Oracle's
Application Server, Spring, and TmaxSoft's container.
Although there is a feature that allows us to explicitly detect the
DatabasePlatform at runtime, it is also possible to explicitly specify
it. See the toplink.target-database property in the following document:
http://www.oracle.com/technology/products/ias/toplink/jpa/resources/toplink-jpa-extensions.html#TopLinkDBSessionAppServer
This property allows the use of any of a list of predefined values or
the use of the fully qualified DatabasePlatform class name. So... users
can be using SQLAnywhere platform without it being automatically
detected and could potentially override our detected settings when we do
detect it.
>(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.
>
>
Our philosophy is to limit to the maximum extent possible the changes a
user that is upgrading has to make. To make this kind of a change, in
general, we require a clear demonstration of improved functionality in
the product. Although, it is possible, the platform you are
contributing, is "cleaner", that is an abstract concept rather than the
kind of clear demonstration of improvement we look for. To provide a
clear enough functionality improvement, we have to address JConnect.
Otherwise, it is difficult to justify replacing the existing platform
and we would be more inclined to check use a different name.
>(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.
>
>
I agree, performance is key. We definitely should not be checking the
driver after bootstrap.
-Tom
>Have Fun
>Markus
>
>