[jbosstools-dev] Re: db dialect question

[Max Rydahl Andersen]

> > No, what should it based the cache on ?
>
> Firstly I think just simple properties: databaseName & 
> databaseMajorVersion be suitable...
>
But neither of these are available without doing a connection.
>
> If useJdbcMetadata and databaseName == null & databaseMajorVersion == null
>
> Then get connection and initialize as it is. So it call getConnection 
> only once -- but this is SettingsFactory -- not suitable solution...
>
> It seems like a "if ( useJdbcMetadata ) {" block -- not a right place 
> in SettingsFactory -> buildSettings, seems should be parameters for 
> buildSettings function - databaseName, databaseMajorVersion. 
> databaseName, databaseMajorVersion -- should be initialized from other 
> place.
>
Or simply just do the detection outside SF and set the dialect.
>
> Just setAttribute("hibernate.temp.use_jdbc_metadata_defaults", true) 
> or autoConfigureDialect (better if not a job of hibernate core) could 
> be a nice feature,
>
Then only do that when you know the configuration is to be used with 
reverse engineering and thrown away again.
The reason I removed it was that for all other usecases of configuration 
(code completion and code generation based on hbm.xml/existing entities) 
requiring the
database to be connected is bad since the db is not needed and it causes 
massive ui freezing.
>
> It prevent user to make one more configuration step to setup dialect 
> by hands...
>
> It' a pity if not possible to use 
> "hibernate.temp.use_jdbc_metadata_defaults" or autoConfigureDialect ...
>
> May be the solution is to get databaseName & databaseMajorVersion or 
> in general dialect in independent thread -- only synchronization issue,
>
again, hibernate core should not care about this and it should 
definitely not created separate threads.

Calling hibernate in a seperate thread/job in the tooling might be a 
solution though.
>
> So Hibernate Console Config could display it's nodes and in case when 
> the user try to expand "Database" (here is a try to connect to db in 
> any case) - db dialect could get its value. But in case if db dialect 
> doesn't get value -- the user should specify this by hands... Look 
> like too much "could" and "but", but this is only specific cases -- in 
> general it seems useful and possible to use (autoConfigureDialect in 
> independent thread). In the bad case we just get a long running thread.
>
There really arent much magic to this - just check if the dialect is 
set, if not try and detect it based on jdbc url, driver class name, dtp 
connection etc. and only if that fails you will have to ask for it.
Same thing you would have to do when your long running thread terminates 
with an error.

-max
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20090703/ed6977bf/attachment.html