Thanks for the suggestions .

• org.hibernate.dialect.Dialect#registerKeywords: as Steve already said in a previous comment, this is only used when automatic quoting of keywords is enabled, which by the way is disabled by default and we don’t recommend it so I think the default behavior should be fine.

• org.hibernate.dialect.Dialect#buildIdentifierHelper: we could consider a setting for this, specifically quoted and unquoted identifier case strategies, though the defaults seem pretty sensible - wdyt ?

• org.hibernate.dialect.Dialect#supportsJdbcConnectionLobCreation: it doesn’t look like the metadata is used to access jdbc information / connections in neither the default implementation or any of the overrides; the javadoc even specifies that the DatabaseMetaData parameter can be used to check database version, but that’s already available through Dialect#getVersion().

Care to elaborate?

An application starts. The database is not accessible yet, because the rest of the environment is still starting up.

I don’t know what more there is to say: this is in no way related to the Quarkus programming model.

I’ll grant you this is probably specific to containerized applications and/or Kubernetes, where you basically start your whole environment by pushing a file to OpenShift, which will provision and start all applications/databases in no particular order.

But then, WildFly/EAP/Spring can be containerized and used on OpenShift too.

In 20+ years of integrating with JBoss/WildFly/EAP this is the first time I have ever heard reference to this

Right, see above, this was probably less of a problem 20 years ago, since Kubernetes was released 9 years ago.

We decided to possibly allow them to be hooked into the new auto-generated settings documentation stuff that Marko and I worked on.

Thank you, that looks great!

If anyone would like to highlight some additional dialect-specific features that would need configurations other than the ones I listed in my previous comment please let me know.

Thanks!

I think you might want to have a look at these, which seem to rely on database metadata to initialize the dialect, though indirectly:

• org.hibernate.dialect.Dialect#registerKeywords

• org.hibernate.dialect.Dialect#buildIdentifierHelper

• org.hibernate.dialect.Dialect#supportsJdbcConnectionLobCreation

But IMO it’s fine if the result is just opening a Jira for later and referencing it from the documentation. There are probably others we didn’t spot, so it seems reasonable to do as well as possible right now and then improve iteratively.

With WildFly/EAP too

Care to elaborate? In 20+ years of integrating with JBoss/WildFly/EAP this is the first time I have ever heard reference to this.

With Spring too, one may need to start the application without access to the DB

No idea, I am not a Spring user. But I have also never heard this requirement from them directly.

Nothing prevents anyone from documenting these switches though… ?

We decided to possibly allow them to be hooked into the new auto-generated settings documentation stuff that Marko and I worked on.

After some more discussion with the ORM team, we agreed to opt for introducing some custom properties to allow configuring this behaviors where needed. As a note, this properties will be named like hibernate.dialect.{db-name}.{thing}, since that from has already been used for customizing some dialect-specific behaviors (e.g. hibernate.dialect.oracle.prefer_long_raw).

If anyone would like to highlight some additional dialect-specific features that would need configurations other than the ones I listed in my previous comment please let me know.

Quarkus wants to allow a different programming model, which is awesome, but that is going to mean a few limitations which I am personally fine with.

With Spring too, one may need to start the application without access to the DB. With WildFly/EAP too. This specific change is not about the Quarkus programming model. And the limitations are not specifc to Quarkus, either.

> I’d personally suggest a more robust and future proof solution, one that would force dialect implementors to handle both cases. E.g.:

And get into even more undocumented switches.

Nothing prevents anyone from documenting these switches though… ?

IMO whatever we do, there’s documentation to be added. Either we document the limitations of offline startup and say there’s no workaround, or we document the limitations of offline startup and list specific configuration knobs to work around these limitations, in the same section of the documentation.

Yes, new configuration switches may not be documented in the future if a PR is merged without being careful about documentation. But the same could be said of any configuration switch, not just these.
Compile-time safety can’t really help here, or at least not without extreme, probably very inconvenient changes (e.g. a static metamodel for properties, and inability for configuration to be retrieved through any other means than this static metamodel). I wouldn’t want to go there.

To me, I guess it comes down to whether we are ok with undocumented settings. I’m fine adding hooks like you suggest, but I think documenting those is really more a Quarkus thing

Quarkus wraps all configuration with its own property keys starting with quarkus.. So Quarkus will necessarily document every configuration property it exposes, regardless of what Hibernate ORM documents. But it will certainly link to the Hibernate ORM documentation on occasion, e.g. for the more complex or obscure concepts, so it helps if ORM documents what it exposes to users as well.

Can I suggest a few “unnecessary” settings for Search?

All suggestions welcome, though like you I retain the right to reject them after careful consideration