Hibernate version: 3.1.3

This is a more general question about what something in the documentation means (or is supposed to mean, perhaps).

The first paragraph of section 13.4 of the Hibernate Reference Manual implies (the way I read it) that if I use HQL instead of SQL that the state of objects in memory will be updated along with the database.

In practice, I have found that this is NOT true - at least for one case.

So the question is: Is my reading of the reference manual wrong (in which case I would strongly urged that it be revised to unequivically remove the implication) or is this a code problem (either a bug in my code or a bug in Hiberbate)?

If the later is true, I will try to create a reproducable test case that I can post.

Thank you,

Donald

I don't see that implication anywhere in that paragraph. It's certainly not true: there is absolutely no way to make a change to the DB directly, and expect hibernate to update in-memory objects.

The paragraph is trying to say that if you use JDBC to do your bulk updates, then any in-memory objects that represent updated rows won't be affected; however, if you use those in-memory objects to update the DB, via HQL, then the problem never arises.

The first sentence talks about how ORM "is concerned with the management
of object state" - and of course Hibernate is an ORM package. This suggests that the subject of the paragraph deals with in-memory state.

The second sentence says that if you use raw SQL that, of course the in memory objects will not be updated.

The third sentence starts with the word "However" and talks about doing updates in HQL.

If that isn't an implication then the word needs to be stricken from the language cause there ain't no such animal.

What the paragraph should REALLY be saying is something more along the lines of:

Bulk updates of any kind (HQL or SQL) will not affect the state of objects in memory. The big advantage of using HQL is that in many cases, it produces more readable expressions.

Ambiguity is a developer's most powerful documentation tool :)

I don't think that your interpretation of what the paragraph should be saying is entirely accurate. It would be closer to say "If you use HQL to persist changes you've made to in-memory objects, the out-of-sync problem doesn't arise.".

Don't forget that this is an open source project, with developers from around the world. From time to time, leniency should be granted to their documentation: it's a hell of a lot better than some open source projects' docs. Plus, some of the key developers are Australian! They learn their English from Foxtel!

(Spot the NZer ;)

I'm not trying to be critical - I'm trying to be helpful by making a suggestion, or at least opening a dialog during which a better approach to the documentation can be found.

There's a point here where we have a communications mismatch and until we resolve it, we are going to be talking about different things. Let me try and explain (as a new user) how I read the manual and how my thought processes led me misinterpret it and why it should be rephrased.

I'm sure that I don't have to remind you that the manuals are more for newbies like myself than they are for people who already understand what the manual really means.

My situation was that I have an update that I want to perform and I don't know if the affected objects are in memory or not. If they aren't in memory there's no reason to load them and if they are, I want to update the in-memory copy as well as the copy on disk.

So I go looking in the manual and there's a section "Bulk Updates" and I read through it and find the secion on DML style operations and I read the first paragraph and it appears to be saying that it is exactly what I want. Only, of course, we both know that it isn't, that the HQL they're talking about only updates the data on disk - but allows some useful and expresive query constructs that aren't part of standard SQL.

Just to be clear, I think that the kind of updating that you are refering to is covered in section 13.2 - Batch Updates.

Donald
[edited to fix grammar error]

Fair enough. I've always considered that the reference docs are intented to be docs that are referenced, rather than a manual. In the same way that a dictionary can't teach you a language, the ref docs can't teach you hibernate. I suppose I'm wrong about that though, as there is nothing else to teach you hibernate (or at least, nothing that doesn't cost $50 down at the bookstore).

Right, now to find whoever maintains the ref docs and point this out to them...