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

[Steve Ebersole]

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