|
question & rant
OK, I know this has been asked before, I have seen it posted, but I have not found a solution after looking long and hard. I want to see the actual SQL that hibernate generates along with the data in a log file or be able to dump the actual SQL to a log file that I specify.
In only one instance I am seeing SQL problems but am having a hard time knowing or seeing the actual (or partial) SQL generated (for some SQL statements the SQL is not printed even with the sql enabled param turned on).
I know there is a param to enable sql printed to the log file, but it does not include the data an only prints the ?, ?, ? what I want is the data replaced by the ?, ?, ? and be able to log this.
---
Furthermore it would be helpful if I could selectively log the statements for which an exception is thrown (sqlexception or other hibernate related exception involving the execution of the sql statement).
---
Someone suggested a way to log data by writing a toString() method on every hibernate object and logging this or putting try {} catch{} throughout my application but this is the wrong way to go about it.
If Hibernate does not have the most basic facility for me to debug my application (using the framework) by seeing what it is actually doing, we will be looking elsewhere and possibly implementing our own ORM framework.
Every interface or wrapper that I have written around JDBC supports the facility to see what it is actually doing in case there are errors and to log detailed information that will help find those errors.
In order to find the problem (any problem), you have to understand what the problem is and to understand the problem in this case it is to see what is going on (what data is being passed in each field).
I don't want (and should not have to) rewrite my entire application to do something the framework should provide, namely see exactly what it is doing when there are errors.
If there is a SQL Exception or problem of any kind, there should be a facility for:
1. Logging the problem (the actual SQL that caused the problem - actual SQL is defined as the actual statement, with the data, that is being sent to the DB)
2. Sending notification (email, pager) if needed
3. Provide a development setting that exits the app server and blows smoke out of the back of the machine when a designated problem occurs.
I know there will be people who disagree with #3 but in the software development world, it is called fail fast (and hard) which during development is what I want to do so that the annoyance factor is so high that every developer on my team sees the problem and it gets fixed as soon as possible. I am also implementing this is any other config file can not be read or parsed properly during startup.
---
I would appreciate any help, or at least a discussion in this area. There is a considerable amount of time being spent on debugging problems with Hibernate. I have seen this on more than one project and am weighing the time saving costs that are touted by the framework.
---
I grant that using Hibernate may save development time if the framework is used as intended, and everyone knows what they are doing, but I have seen some horrible things on projects that I come into where the self proclaimed architects have strangled themselves with Hibernate (and other frameworks in use on the project).
A framework used badly can lead to longer development times. I recently worked on a project using Hibernate and EJB together that should have taken only six months to complete, yet it was two years into development, hardly finished (and it was a real terd). They are still trying to polish it.
If I can figure out this SQL thing with Hibernate my faith may be restored and the Universe will be closer to order again.
r
|
Login
FAQ
Search
