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

[Max Rydahl Andersen]

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 ?

> 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 <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