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 <st...@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? >>>> >>>> -- >>>> st...@hibernate.org >>>> http://hibernate.org >>>> _______________________________________________ >>>> hibernate-dev mailing list >>>> hibernate-dev@lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> >> >> -- >> st...@hibernate.org >> http://hibernate.org >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > -- st...@hibernate.org http://hibernate.org _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
