Re: [Fwd: Proposed code changes to automatically detectdatabaseplatform]
+1
Sahoo
Mitesh Meswani wrote:
> Hi Gordon,
>
> I think there is some confusion about how this feature works. If user
> has specified "toplink.platform.class.name" in persistence.xml, no
> effort would be made to auto detect the platform. Else, we will try to
> guess the platform using information from DatabaseMetaData.
> We are trying to achieve two things here.
> 1. Get away from specifying redundant information about the target db
> in persistence.xml. That is once in form of connection properties and
> again specifying platform for the same db
> 2. Improve out of the box user experience for new users without
> complicating life of existing users in any ways.
>
> We have been successfully able to use this feature without any
> maintenance effort since long time against various db and driver
> combinations.
>
>> We should however be concerned with overloading users with points of
>> configuration.
>> Being able to configure the same setting in multiple places can
>> sometimes make things more confusing for users.
>
> Can you give some more details.
> As you mentioned, we can improve on this solution, if we come across
> any short comings.
>
> Thanks,
> Mitesh
>
> Gordon Yorke wrote:
>
>> Hello Marina,
>> My concern is that although we may be able to guess for the
>> simple cases if custom configuration is not given special attention
>> users who's configuration lies outside the simple cases will become
>> lost attempting to configure their systems. Confusing configuration
>> will reduce usability. As well this feature has the potential for
>> high maintenance and QA costs, as every new release of a supported
>> platform will need to be tracked.
>> Perhaps we can work together to improve this solution to provide both
>> ease of configuration and portability of persistence.xml files. We
>> should however be concerned with overloading users with points of
>> configuration. Being able to configure the same setting in multiple
>> places can sometimes make things more confusing for users.
>> --Gordon
>>
>> -----Original Message-----
>> From: Marina.Vatkina_at_Sun.COM [mailto:Marina.Vatkina_at_Sun.COM]On Behalf Of
>> Marina Vatkina
>> Sent: Thursday, December 15, 2005 3:53 PM
>> To: persistence_at_glassfish.dev.java.net
>> Cc: Lance J. Andersen; Pramod Gopinath
>> Subject: Re: [Fwd: Proposed code changes to automatically
>> detectdatabaseplatform]
>>
>>
>> Hi Gordon,
>>
>> As EJB 3.0 and Java Persistence are all about ease of use (EOU),
>> we should be able to help users to simplify their life by providing
>> the "best guess". Our experience shows that this guess is quite good,
>> and we can maintain the file as we go and identify new options.
>> In case a particular configuration can't be detected correctly, or it's
>> a new database, the user will be able to choose the correct or the
>> best matching platform in the properties.
>>
>> If we are talking about spec enhancement, it'd be much more important
>> to standardise on Java SE jdbc properties for the
>> url/driver/username/pwd
>> combination, to avoid learning vendor specific names for these
>> absolutely
>> generic properties.
>>
>> regards,
>> -marina
>>
>> Gordon Yorke wrote:
>>
>>
>>
>>> Hello Mitesh,
>>> I guess I should have been more clear but what I was trying to
>>> express was that this feature is and will be quite limited in
>>> usability. Capturing a useful set of 'Vendor Keys' will be daunting.
>>> Using this feature to run demo's has some merit for DDL generation
>>> but we should encourage users to select their own platform.
>>> I think this should be brought up with the spec committee.
>>> --Gordon
>>>
>>> -----Original Message-----
>>> From: Mitesh Meswani [mailto:mitesh.meswani_at_Sun.COM]
>>> Sent: Thursday, December 15, 2005 2:52 PM
>>> To: Lance J. Andersen
>>> Cc: persistence_at_glassfish.dev.java.net; Pramod Gopinath
>>> Subject: Re: [Fwd: Proposed code changes to automatically detect
>>> databaseplatform]
>>>
>>> Lance J. Andersen wrote:
>>>
>>>
>>>
>>>> Mitesh Meswani wrote:
>>>>
>>>>
>>>>
>>>>> Hi Gordon,
>>>>>
>>>>> The current property file contains mapping for all the databases
>>>>> platforms that we currently have access to. It would be great to have
>>>>> mapping for all the platform in the property file. Mapping for
>>>>> following platforms are missing in the property file
>>>>>
>>>>> AccessPlatform
>>>>> AttunityPlatform
>>>>> CloudscapePlatform
>>>>> DB2MainframePlatform
>>>>> DBasePlatform
>>>>> HSQLPlatform
>>>>> InformixPlatform
>>>>> SQLAnyWherePlatform
>>>>> TimesTenPlatform
>>>>>
>>>>> Is it possible for you to provide what does
>>>>> DatabaseMetaData#getDatabaseProductName() return for above platforms
>>>>> for various supported driver combination. I will update the property
>>>>> file with appropriate regular expression corresponding to that.
>>>>>
>>>>
>>>> getDatabaseProductName() will/can differ based on the JDBC Driver
>>>> being used. For example jConnect kept all of this in set of tables
>>>> that you had to initialize so the value changed as the product name
>>>> changed. the DD drivers also used to specify a different name (as an
>>>> example) for sybase
>>>>
>>>
>>> The return value of getDatabaseProductName() does vary based on the
>>> driver being use. However, the proposed mapping property file can
>>> successfully detect vendor for the supported databases using native,
>>> data direct and inet drivers.
>>>
>>> Thanks,
>>> Mitesh
>>>
>>>
>>>
>>>>> Thanks,
>>>>> Mitesh
>>>>>
>>>>> Gordon Yorke wrote:
>>>>>
>>>>>
>>>>>
>>>>>> When connecting to SQLAnywhere or SybaseIQ the SQLAnyWherePlatform
>>>>>> should be used. The known vendors in the properties file should be
>>>>>> expanded to cover all supported databases with the correct platform.
>>>>>> --Gordon
>>>>>>
>>>>>
>>>>>
>>>>
>>
>>
>>