> 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