Quote:
For example.. suppose a developer asks me to create a table and then he/she subsequently implements constraint checking using Hibernate. If I go and make changes to the table myself using my own scripts I'm likely to break this table because I'm not aware the constraint exists.
Actually it is usual for Hibernate to delegate constraint checking to the database. We assume that the DB itself implements foreign key, unique, check constraints, etc.
Indeed, if you use Hibernate to generate the DDL (you don't have to do this) then you can indicate the correct unique and check constraints in the mapping file and they will be included in the DDL (foreign keys are added automatically).
Of, of course, you can simply write the DDL yourself and add triggers etc.
Quote:
Another concern I have is with performance tuning. If I'm seeing a great performance hit will it be enough to simply look at my developer's code when I try to optimise or will I need to look deep into the mechanics of Hibernate?
Usually you would look at the generated SQL, and then figure out what changes should be made to the Hibernate query (this is usually very easy). In a pinch, you can just modify the SQL directly and use Hibernate's support for native SQL queries.
We usually advise people to use named queries (ie. queries in metadata) when they are working in an environment with a proactive DBA. That way, all query tuning can be done by meddling with just the XML metadata, no Java coding is needed.
You just reminded me of something that I mean to add to the TODO list:
I want the name of a named query to appear as a comment in the generated SQL, so that the DBA can easily find the HQL query in the metadata.
Actually, we should also add a setComment() method to Query interface, for the same purpose. I'll add this stuff today or tomorrow; its very useful, I think.
P.S. I should say that we are extremely receptive here to input from DBAs and we consider it absolutely critical that Hibernate addresses the concerns of people on the data side.