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

Correct. The current proposal has them passed in as settings.

Yes, we could "mock" DatabaseMetadata, but there is a lot there including access to the Connection from which the DatabaseMetadata was supposedly retrieved.

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(a)hibernate.org&gt; 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(a)hibernate.org >>>> http://hibernate.org >>>> _______________________________________________ >>>> hibernate-dev mailing list >>>> hibernate-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> >> >> -- >> steve(a)hibernate.org >> http://hibernate.org >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > -- steve(a)hibernate.org http://hibernate.org