Hi Markus,
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.
-Tom
Markus KARG wrote:
>Tom,
>
>
>>My concern related to checking in the current code is that there is
>>already a SQLAnywherePlatform. As Markus has correctly pointed out,
>>his design makes more sense because the current implementation is a
>>subclass of the SybasePlatform and that does not reflect the reality
>>of how SQLAnywhere is designed. For the JConnect case, however, the
>>fact that we are currently a subclass of SybasePlatform likely
>>benefits us.
>>
>>
>As I wrote before, jConnect is not able to access every SQLAnywhere
>database instance. The administrator must have enabled support for
>jConnect inside of the database instance, and (AFAIK) you must enable
>ASE emulation mode. After that, it is no more a "pure" SQLAnywhere
>database (in the sense of its vendor, iAnywhere company, a Sybase
>subsidiary). I understand your issues but see, what I implemented is
>"pure iAnywhere" (it supports everything that is in the box, but only
>that). If you want to provide more (that is not in the box) just of the
>reason that you did it before, then I do not see a big problem in
>telling people "hey, you're doing things that are not in the box, so YOU
>have to change over that the renamed, old platform). That's why I think
>MY platform should be called SQLAnywherePlatform (it does what is in the
>box), while the OLD SQLAnyWherePlatform should be renamed to
>"LegacySQLAnyWherePlatform" or something. Just to make clear what the
>truth is. For future, jConnect support should be added, but we have to
>carefully decide where to put it. Either in an inner class of my new
>platform, or in a separate platform, or (my favorite) make TopLink learn
>that a driver and a dbms are two different things and such can be in N:M
>combinations -- split up DatabasePlatform into a driver part and a dbms
>part.
>
>
>>Perhaps we could rename Markus' version of the platform to reflect the
>>fact that is only covers the iAnywhere software, but I am somewhat
>>concerned about adding extra classes if they are not needed since if
>>we have too many platforms, it may become difficult for users to know
>>what to use. Do you think it would make sense to users that we would
>>represent SQLAnywhere in two different platforms?
>>
>>
>Yes. Because mine is what is in the original SQLAnywhere product box and
>everything else is some kind of "handicrafts" made up switching around
>database options and installing a driver that has to be pulled manually
>somewhere on the Sybase web site (the holding, not the SQLAnywhere
>vendor actually -- if you buy SQLAnywhere today, on the box is not a
>Sybase Logo but an iAnywhere Logo; while on the jConnect driver there is
>a Sybase Logo but not an iAnywhere logo; just to make it clear once
>more). ;-)
>
>
>>As far as testing is concerned, the TopLink Essentials product has had
>>limited testing with Sybase. The full TopLink product, however, uses
>>basically the same platform code and has run through extensive testing
>>on SybaseASE 12.5 using the JConnect 5.5 driver.
>>
>>
>I think it is good advice to let run all the tests again with jConnect
>6.0.5 since from the major version number change I could imagine that
>there had been numerous changes.
>
>Have Fun
>Markus
>
>