and having On 31 Aug 2012, at 01:59, Steve Ebersole <st...@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 ? > 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 ? /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 <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
