Sanjeeb Kumar Sahoo wrote:
> +1
>
+1.
EOU, EOD (as stated in the first paragrah of the spec) , KISS (from a
developer perspective). Avoid redundancy. Zero config concept (or as
close as possible) by default.
Use CPU power when we can help the developer.
Theme: Developer works less. Containers work more...VB, RoR...
Ludo
> 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
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>
>>>
>>>
>