I read https://www.hibernate.org/hib_docs/tool ... ering.html, section 5.2.4.3 <foreign-key>. Here are the questions that that chapter leaves open for me:

• 1. What's the difference between <many-to-one> and <set>? I assume <set> is what you use for modelling one-to-many relationships, but is that correct?
• 2. What's the difference between <one-to-one> and <inverse-one-to-one>?
• 3. What will happen for <many-to-one>, <one-to-one>, and maybe <inverse-one-to-one> if there are multiple matching rows on the foreign table? This might happen if the foreign key is explicitly specified and not inferred from the database.
• 4. What will happen if I specify more than one of <many-to-one>, <set>, <one-to-one>, and <inverse-one-to-one>? (<many-to-one> and <set> in conjunction will ignore <set> if no property name is given, but that's just one data point. I'm almost sure that many if not all of these combinations do not make sense and should be forbidden.)
• 5. I see the documentation for the "property" and "exclude" attributes, but not the documentation for "cascade", "fetch", "insert", or "update". Is there any? If yes, where?
• 6. What are the defaults for the four undocumented attributes? Oh, and while I assume the default for "exclude" is "no", it would be nice to see that spelled out in the reference manual - it helps defining what purpose "default" is for.
• 7. For "cascade", since the DTD does not restrict the value in any way, it's even unclear what to enter here. I dimly recall a selection of comma-separated fetch/insert/update words, but are blanks allowed? Is order relevant?
• 8. What exactly does "cascade" mean anyway? I was assuming I'm either writing out everything with a commit, or nothing with a rollback - does a non-cascaded update somehow magically ignore changes in the referred-to
• 9. For "fetch", it is unclear when one would use "join" and when "select". Is this just
  (A) selecting between semantically identical JOIN vs. sub-SELECT, or
  (B) does this switch between single-fetch JOIN and two-fetch SELECT main_table, then SELECT foreign_table WHERE (keys) IN (values encountered in first SELECT)?
• 10. If (A), is this there just an optimization for specific databases? Or does this have other ramifications?
• 11. If (B), fetch="select" would make sense only for <set>, not for the <*-to-one> elements.
• 12. What does "insert" and "update" on <many-to-one> do? Why is there no "delete" on <many-to-one>?

I manually numbered each question to make it easier to refer back to each, as the [ list= ][ /list ] markup generated from the List= button above the text input field would not work.

Thanks for any answers. I know the list of questions is overly long, but googling gave me mostly irrelevant forum posts, example XML that never quite covered my use case, or ages-old posts where I'm unsure how much of that still holds.

I still need that information... without it, I'm forced to trial-and-error and follow-the-recipes programming, which both is a huge waste of time.

I also need to tell you that the documentation explains these, if not buy the book, attend a training, get a support contract or at least post to the user forum instead of the tools forum.

This is about hibernate.reveng.xml.
Not about the workings of Hibernate itself, which I've been using to good effect.



Um, sorry, no.

That list of questions is the direct result of working through the "Controlling Reverse Engineering" chapter, at https://www.hibernate.org/hib_docs/tools/reference/en/html/reverseengineering.html.
It is the list of questions that were left open after I finished reading and re-reading the entire chapter around half a dozen times, and then again reading each sentence to be able to even clearly write these questions down. They are not answered in that chapter.

That does not mean they aren't answered elsewhere. I'm pretty sure they are. There's a whole list of reasons why I don't find them, which I won't bore you with.
But I'd really appreciate links to the answers. I can work from there.



Been there, done that.

Well, bought "Java Persistence with Hibernate".
Very useful for using Hibernate, but not for Hibernate Tools, on which it has nothing. (Pp. 88-96 dwell on the corresponding Ant task. It remains unclear what version of the tools it documents, nor whether the Ant task's reveng.xml files are the same as that of Hibernate Tools, nor does it go beyond what's in the online docs.)

Is there a book for Hibernate Tools?

Well, thank you for nothing, Max.
Getting RTFM answers after repeated rounds of RTFM on my side, and no more answers after I state that fact... well, seems like you'd like me to go away.
Fine, I can comply with that. Just don't expect glowing review.

Seriously pissed,
Jo

P.S.: The docs really have problems.
The content is accurate but incomplete and/or lacks a cross reference from Tools features to the corresponding Hibernate feature. The correspondence may be trivial for an Hibernate expert, but it certainly isn't for those who are just starting with Hibernate and Hibernate Tools.
Not that I expect any of this to be heard.

Hey, I got a zero-helpful RTFM answer.
In particular, a zero-helpful RTFM answer after spending days reading up things and collecting the questions for the list.
A zero-helpful RTFM answer from a person who didn't even care to try and find out what exactly the problem might be.
A zero-helpful down-the-nose RTFM answer, alluding that I didn't even properly research before posting my question - the exact opposite of what I did.

I have every reason to be angry.

I have taken the anger out of the rest of the post. It required a good deal of rewriting, but I feel you're honestly trying to clear the thing up, and that deserves better than an unedited first draft.



I have the first book already (as you acknowledge), and the second isn't about reverse engineering, it's about full-text search.
That leaves me puzzled: Why are you giving an answer that you already know can't help?



I was seeking answers in the form of "reveng will generate FOO for <many-to-one> and BAR for <set>", with FOO and BAR being Hibernate concepts.

I'm not unclear about what Hibernate does.
I'm unclear about how exactly the reveng process maps reveng.xml specifications to Hibernate mechanisms. (Or is supposed to map things. There's still the possibility of bugs, and documentation is essential to distinguish unexpected but intentional behaviour from buggy, soon-to-be-changed behaviour. I have learned not to rely on the results of experimentation, that's not future-proof. Particularly not if things are still under heavy development - old, mature software like, say, GNU make could be experimented with to find out things and rely on the results.)



Yes, I know how hard it is to write docs that work for novices and experts.
However, I'm really asking for reference information. That's relevant to experts and novices alike (well, novices after they start to ask questions that aren't covered in the tutorials).

I guess I'm still out in the cold.

Well... after the heights of "maybe I'll get an answer that helps me along after all", I'm back to being deeply disappointed and regretting I ever decided to use Hibernate Tools.

Hibernate Tools documentation is in a shabby state, but as soon as I'm seeing clearly enough to substantiate where the problems lie, the team goes silent.
I guess there's no interest in the team in fixing this. I'll leave it to readers to decide whether that's due to an understaffed team, or due to incompetence on the team's or my side; frankly, I'm beyond the point where I care about reasons.

My project strategy is in shambles.
The upgrade to 3.3.0 almost broke the reveng setup; some part of the Oracle reverse engineering changed, and I got different data types big time.
I was very lucky, as it took me only a day's work to explore fixes and find one that would restore the types that I needed.
On the day I fail to fix that kind of problem, I'll be forced to nail Hibernate Tools to the last working version, which means they'll operate in a state of bit rot. That's going to be more and more agonizing over time, until the tools cease to function - on that day, the project will die, and my job with it.

I don't have a way to acquire the knowledge to reliably control the reverse engineering process.
I don't know how to make the team produce the docs so I can acquire such knowledge.
I don't have a viable exit strategy away from Hibernate Tools.

If I'm lucky, an alternative to Hibernate Tools will present itself.
If I'm even more lucky, the Hibernate Tools docs will improve.
If I'm unlucky, reveng will irrecoverably break for me before any of the above happens.
I can't do anything to make one or the other happen, so it's pure chance whether I can keep my job.

I hope nobody expects I'm grateful for all this.
Except in the "grating my teeth" sense, maybe.

Hi. If you saw differnences in codegen between versions that were not what you would call bugfixes then Please report it n JBIDE or HBX jira.

Sorry for being short but dragged down by release and clecliosecon right now.

It's working well enough for me.
Anyway. Given history I doubt that reporting anything is worth the time if I do it.