Tom Ware wrote:
> 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?
There can be some subtle differences when using jConnect (or any other
JDBC driver which access ASA via TDS) vs using ODBC to talk to ASA.
There are some limitations due to TDS restrictions, that would not
necessarily be there if you were not using TDS. I do understand the
reasoning for a pure ASA play that in some scenarios, the ianywhere
driver while based on ODBC, can be advantageous.
TDS support was added to ASA if I recall for ASA 5 as part of working
on a ASE/ASA compatibility story. The majority of the changes were to
make ASA to have more ASE features not ASE have more ASA features. I
would expect that ODBC is much more performant then using TDS to
communicate to ASA especially if everything is located on the same machine.
>
> 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.
Backwards compatibility is also important.
>
> -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
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>