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