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
> >>
> >>