[hibernate-dev] org.hibernate.engine.jdbc.dialect.spi.DialectResolver

[Steve Ebersole]

On Aug 31, 2012 3:02 AM, "Max Rydahl Andersen" <max.andersen at redhat.com>
wrote:
>
> and having
>
> On 31 Aug 2012, at 01:59, Steve Ebersole <steve at hibernate.org> wrote:
>
> > Correct.  The current proposal has them passed in as settings.
>
> okey, so I must be missing something - since no access to database
metadata how is the autodetection of name/version supposed to work when
users have not passed in the settings ?

Two different things:
1) Auto-detection is something we do while building the sessionfactory.
2) JPA defined schema export which Linda wants to have work even when the
database is not available (no different from our current SchemaExport
really)

Auto-detection while building the sessionfactory *will* have access to the
dba metadata or building the sessionfactory will fail.  Though maybe we
also add recognition of these JPA config values, then determining dialect
would be:
1) explicit dialect
2) explicit  JPA db/version sittings
3) querying the jdbc metadata, if available
4) fail

That is actually exactly what we do today except that (2) would be new
addition.

The argument against adding (2) is that these JPA settings are meant for a
very specific purpose

>
> > Yes, we could "mock" DatabaseMetadata, but there is a lot there
including access to the Connection from which the DatabaseMetadata was
supposedly retrieved.
>
> And something like would be too weird:
>
> public Dialect resolveDialect(String dbname, String version,
DatabaseMetaData dbmetadata)
>
> Where dbmetadata is null if not available ?

Well that is an option.  Let's see what others think.  But I am not a fan
of passing in just the single String version.  I brought this up to the JPA
group too and it looks like this will change there to allow access to (int)
major/minor.

>
> /max
>
> > On Thu 30 Aug 2012 02:31:56 AM CDT, Emmanuel Bernard wrote:
> >> I imagine the DB name + version will be provided by the user somehow.
> >> We could also have Hibernate build a DatabaseMetadata implementation
returning the data provided by the user.
> >> That would avoid changing the contract. The main drawback is that
DatabaseMetadata has many more methods
> >> we would not be able to honor.
> >>
> >> On 29 août 2012, at 19:58, Steve Ebersole wrote:
> >>
> >>> Like I said in the original email, the connection may or may not be
> >>> available.  Which means we cannot rely on it being available.  Nor do
> >>> we rely on it being available today either btw.  The difference is
just
> >>> that today in those cases we expect the user to manually name the
> >>> dialect to use.
> >>>
> >>> On Wed 29 Aug 2012 12:26:17 PM CDT, Max Rydahl Andersen wrote:
> >>>> hmm - any reason why jpa won't pass in DatabaseMetadata ?
> >>>>
> >>>> how would one identify name and version anyway if that is not
available ?
> >>>>
> >>>> /max
> >>>>
> >>>> On 29 Aug 2012, at 16:43, Steve Ebersole <steve at hibernate.org> wrote:
> >>>>
> >>>>> I think we need to consider changing DialectResolver to fit with
some
> >>>>> upcoming JPA 2.1 features.
> >>>>>
> >>>>> JPA 2.1 is adding some form of schema export.  The initial plan
there is
> >>>>> to identify the "dialect" to target by passing in the (1) database
name
> >>>>> and (2) database version as it would come from JDBC
DatabaseMetaData.
> >>>>> The connection may or may not be available.
> >>>>>
> >>>>> Currently we just pass the DatabaseMetaData to the DialectResolver:
> >>>>>
> >>>>> public Dialect resolveDialect(DatabaseMetaData metaData)
> >>>>>
> >>>>> The original thinking was to support resolvers looking at
information
> >>>>> other than just name/version ion making the determination (or even
in
> >>>>> potentially configuring the Dialect before return).  However all our
> >>>>> implementations are based on just name/version resolution.
> >>>>>
> >>>>> Even worse the current proposal proposes using (String)
> >>>>> DatabaseMetaData#getDatabaseProductVersion whereas we use (int)
> >>>>> DatabaseMetaData#getDatabaseMajorVersion and (int)
> >>>>> DatabaseMetaData#getDatabaseMinorVersion inside the standard
resolver
> >>>>>
> >>>>> So should we change this contract?
> >>>>>
> >>>>> public Dialect resolveDialect(String dbName, int majorVersion, int
> >>>>> minorVersion)
> >>>>>
> >>>>> or
> >>>>>
> >>>>> public Dialect resolveDialect(String dbName, String dbVersion)
> >>>>>
> >>>>> WDYT?
> >>>>>
> >>>>> --
> >>>>> steve at hibernate.org
> >>>>> http://hibernate.org
> >>>>> _______________________________________________
> >>>>> hibernate-dev mailing list
> >>>>> hibernate-dev at lists.jboss.org
> >>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>>>
> >>>
> >>> --
> >>> steve at hibernate.org
> >>> http://hibernate.org
> >>> _______________________________________________
> >>> hibernate-dev mailing list
> >>> hibernate-dev at lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>
> >
> > --
> > steve at hibernate.org
> > http://hibernate.org
>