My understanding is that you usually get this kind of thing from DBAs who are thinking in terms of batch jobs and the issues that affect offline processing, not OLTP. However, I am not myself a DBA, and would be curious to hear a compelling justification for this decision.
Gavin, I totally agree with you.
In our application, we have to do a daily deployment (essentially a bulk loader) which can be invoked outside of the application. I'm no DBA either, but apart from caching, this could pose a problem for the application's availability if during the load, our queries lock up.
Personally, I don't think the collisions are that bad. I think our DBA is coming from a historic angle - previously a deployment could take 20 mins. Our new loader much more streamlined (also built on Hibernate - thanks!) does it in a couple of minutes.
I'm recommending that we ignore this issue until it really becomes an issue.
However, I can see other systems that could rely on bulk loads over long transactions. Isn't that going to pose a problem?
I'm not sure how easy it is to do it but I would think Hibernate can benefit a lot if there are hooks into the query engine. This way developers can extend the language as needed.
For example, what about:
1) calling functions and stored procedures?
2) non supported aggregate functions?
3) keywords like Oracle's decode?
To my limited knowledge, HQLs are translated to SQLs and then object instances are inflated. Hooks into the HQL that allows custom population of the object instances would make Hibernate more extensible/flexible.
I can also see some systems having a 95% fit for Hibernate, but then there's that 5% high performance stuff that needs stored procedure/function calls or batched updates/deletes but I don't want to circumvent the nice stuff I've done to model the application.
Maybe Hibernate can already do this... I'll be happy to hear it if it can and how/where other people are using it.