I am trying to run a junittest with Hibernate. When the session.save() method runs, it does not seem to find the values I have assigned to the parameters to be stored. For example:
From test class: <snip> private static final int departmentId = 444; department = new Department(); department.setCity("City"); department.setState("State"); department.setName("Department Name"); department.setDepartmentId(departmentId); session.save(department); </snip>
I verified the object is fully populated, but when I look at the sql Hibernate is generating, I get: Hibernate: insert into department ( City, DepartmentName, State, DepartmentId ) values ( ?, ?, ?, ? )
It looks to me like the mapping is not working correctly, but I cannot see anything wrong.
The unit test fails prior to performing the commit since the database will not allow a null in the pk column. I assumed that the insert statement would actually include the values to be inserted. So instead of "insert into table(departmentId,name,city,state) values(?,?,?,?)", I thought it should read "insert into table(departmentId,name,city,state) values ( 444, 'Some Name', 'Some City', 'Some State')". Is this not the case?
Hmmm. So if the test fails because the insert is attempting to insert a record full of null values e.g.:
([ERROR] JDBCExceptionReporter - -[IBM][CLI Driver][DB2/NT] SQL0407N Assignment of a NULL value to a NOT NULL column "TBSPACEID=2, TABLEID=3, COLNO=4" is not allowed. SQLSTATE=23502)
and assuming you are correct that the "hibernate.show_sql = true" configuration only shows the prepared statement being used, rather than the actual query being executed, what are my options for determining where the error is occurring and for seeing what query is actually being sent to the db?
Joined: Jun 19, 2001
you are using assigned id generator. so its up to you to assign the ID. if the re is no value assigned, then the not null constraint for the PK will be violated. and yes, you will only see the prepared statements without the real values.
try to assign a value for the id and if this does not help, then show the code where you create the object and store the object.
That is the actual "query" being executed. PreparedStatements are compiled and cached by the DB, when they are reused its just the parameters which are changed.
One thing, you don't specify a type for your property, I know its an implied attribute, not a required one but are you sure the underlying datatypes specified in your DDL can support the values you are passing it? (bit of a long shot - I'd expect a different kind of error)
Joined: Oct 13, 2004
pascal: In my original post, I included an extract of the code including the following two lines:
private static final int departmentId = 444; ... department.setDepartmentId(departmentId);
Are you suggesting this is not enough to assign the pk? If so, what else do I need to do to assign this value?
paul: I was thinking about the "type" issue myself, but could not see how that would cause this. I will try it out anyway just to rule it out.
All the examples I have looked at show the sql output as having the parameters in place in the query (i.e. the substitution has taken place already), rather than the prepared statement, so this is where some of my confusion originates. When I do this with jdbc/sql, even when I use a prepared statement, after making the substitutions (e.g. pstmt.setInt(1,444)), if I print out the query, I see the query with the inserted parameter values which is great for finding why queries do not work as expected. At this point, I strongly suspect that no parameter substition is occurring, but cannot see a way to confirm my suspicion.
Your debug should also show the paramater (and type) which is being bound - "hibernate.show_sql = true" lists this too.
The easiest way to approach this (if you are confident you've not made a mistake) is to run it in a debugger and step into the code - Hibernate after all being open source means the code is easily available. You should be able to sort it out pretty quickly that way.
Joined: Oct 13, 2004
Paul: You give me way too much credit. The only thing I am confident about is that the fault lies with me and that it is a really silly oversight I am not able to spot (honey, have you seen my socks?). The debugger is a good idea, as the System.out technique is not helping. Perhaps it is time for me to evolve beyond text editor as IDE.
Joined: Jun 19, 2001
i should have read your post more carefully.... it looks like your depatmentId is set correctly.
The debugger approach makes even more sense when you try Hibernate's own forums - you'll get a very frosty response from Gavin et al. if you post a problem which you haven't first tried to look at in a debugger. So once you start doing advanced stuff with Hibernate this becomes essential.