Hi All,

Investigating using Hibernate3 for new project, but whilst I'm quite happy with the gerenal development the TDA has raised a few questions that have me a bit stumpted. Points will be awarded for answers ;)

Question 1... (think the answer must be no but would welcome any input ;)

Can Hibernate be statically analysed to determine what SQL will be generated for the queries, inserts etc?

I'm assuming that the answer to this will be detailed unit tests with the SQL logs activated and sent to a separate file?

Question 2...

We're already using plain JDBC/DAO etc., for an existing application, some of these objects will be shared (using xdoclet annotations) to persist them in the new application. The TDA is concerned that (must have read it in a book somewhere) that there will be a high(!) risk of database locking if the two applications don't save to the tables in the same order. Is this likely and is if so is it fixable? I guess we can control this to some extent?

Question 3....

Imagine a title combo box for a new user, titles stored in a look up table (id, desc), separate to the user table. If we create the user in a form bean (struts say) and record the pk of the title. For retrieval of a user in future having the title description would be useful. So we'd map it as an association. To save the original user would we have to retrieve title by pk first or can we create an empty title class and just populate the pk?

Finally I've heard it is posisble with hibernate 3 to update and query using one object across multiple tables? I've found information on doing this for query but not for update. Is this possible?

Many thanks for any info,

Chris.

Hi,

Question 1:
Yes you can see(or reproduce) the SQL, with parameters, etc, that will be generated with the API. See this thread http://forum.hibernate.org/viewtopic.php?t=965749

Question 2:
Didn't get the shared object with xdoclet thing but never had problems with more than one application accessing the database (of course requires transaction, locking, short-live sessions, etc)

Question 3:
Yes.

Question 4:
Need to verify.

Reguards.
Eugênio.

First and foremost, make really, really sure that you understand that Hibernate is quite a bit different animal. Understanding the fact that Hibernate is NOT a 'yet another way of JDBC access', but rather an OBJECT PERSISTENCY machine is really important.



Statically? No (though, I wish it had an 'explain' and 'why' mode :-). At runtime, you can turn on the SQL query output, so that you can see what Hibernate decided to do. Writing (and running) unit tests with Hibernate really pays off.
But, you will probably worry more about the consequences of statement above than the individual querries. Of course, once you see what Hibernate does, you will be able to to 'tune' it -- using left join fetches etc.


The main thing you will have to do is handling the deadlocks (recovery pain seems even harder with Hibernate). The save 'order' can be to some degree defined by your object hierarchy mapping (flush appears to travese that mapping - but I am not sure it's 'guaranteed').

Probably, very important will be how you use Sessions (short, long, shared...), because Hibernate transaction commits all the Session changes; if you throw also kitchen and sink into one Session, you may be in for a surprize).
Not to mention that (if you end up using detached objects, such as in case of detach from a session invalidated by a deadlock), you may end up redesigning your exisiting objects -- see the 'identity' woes, the Set<> issues etc.


In the above case, if I read you right, you may start with a null 'title' to begin with. And learn about using the lazy loading (feches). Often a blessing, sometimes a curse you have to fight.


EVERYTHING is possible in Hibernate 3. Well, everything - when you can push whatever Hibernate won't do into a stored procedure :-).
The problem is figuring out how to do each of those every-things. You only have 841 pages to read, and then figure out the details by studying the source code.
But it will be well worth it, "trust me".

Please, don't forget to rate this rambling -- if it helped at all.

Thanks for the info guys, I'm on holiday for the next week and have the Java Persistance book to read so thanks for pointing me in the right direction ;)