[jbosstools-dev] Re: db dialect question
> 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
Attachments:
- attachment.html (text/html — 6.1 KB)