Hello All,
I do realize why this feature has merits however Novice users are still going to be confused why a different version of the Database Driver mostly works when we auto-detect the incorrect platform.
What happens when the IT group for a production system updates the database driver and our auto-detection starts getting it wrong? The majority of the application is going to work, no one may notice for a while but one particular page (or query) is going to fail because it uses outer joins. The IT group is going to have no idea why it's failing and not know how to fix it. We could have saved them a lot of time and headaches by promoting custom configuration while still providing the ease of use of auto-detection for users who find it is sufficient.
My base point is if we auto-detect well enough that most development systems never need to consider configuration and we do not make a point of bringing configuration to their attention they will be in for quite a shock, which will reflect badly on the RI, when the application does not work in production for as simple a reason as database driver versions.
As this feature goes ahead practical, useful and easy configuration must also be considered and promoted in the documentation.
--Gordon
-----Original Message-----
From: Marina.Vatkina_at_Sun.COM [mailto:Marina.Vatkina_at_Sun.COM]On Behalf Of
Marina Vatkina
Sent: Friday, December 16, 2005 3:42 AM
To: persistence_at_glassfish.dev.java.net
Cc: Lance J. Andersen; Pramod Gopinath
Subject: Re: [Fwd: Proposed code changes to
automaticallydetectdatabaseplatform]
Hello Gordon,
I think we are mixing users in this discussion:
a) Novice users. They need help and EOU more than flexibility.
For these users an auto-detection of platform is a must. Otherwise
they'll be bugging us with questions on what went wrong when
they switched to a different database (and you'll spend cycles
figuring out they they did switch).
b) Experience users. They need flexibility. They will have it
by specifying the platform of their choice to make sure that there
is a guaranteed correct platform.
c) Paying customers. Support people will advise them to specify
the platform of their choice as the best practice.
Does it make sense?
thanks,
-marina
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
> > >>
> > >>