Looked at your PR and as far as I understand, it currently only handles deferred DDL execution in case a DB is not present. That's why I'd propose to name the property something like hibernate.hbm2ddl.allow_deferred.
Right but that's only the beginning and I think in the end a more global setting will make the most sense and be the most usable.
As I wrote more or less in my comment to the blog post, I think that real world cloud applications should not rely on auto-configuration based on a JDBC connection if they'd like to handle the case that a DBMS is not available during startup, but rather configure the necessary parts statically. I also think that real world applications will not rely on hbm2ddl for schema updates/validation but rather have a well defined process for that instead.
I tend to think like you in general but we have evidence of people over the years going in prod even with hbm2ddl=update despite us not recommending it. So I'm incline to embrace this complexity int he framework.
Maybe it is worth looking into expanding the support for non-JDBC metadata aware configuration instead?
I might be wrong but I think all options can be manually set already. |