Hello >> Better terms that are frequently used in relational literature and >> examples are "parent" (referenced record) and "child" (referencing >> record). > > Problem with that is that it doesn't cleanly transfer to one-to-one > relationships. > Also, at least for me, parent-child carries the connotation that if the > parent record dies, the child records should go away, too (i.e. true > hierarchical ownership). I don't know whether that's just me or majority > usage. > > I usually stick with to-one and to-many in my terminology to avoid these > complications.
to-one and to-many are higher-level concepts. SQL only knows references / foreign keys. I.e. there is no such thing as a one-to-one relationship in SQL. Of course, you can combine a foreign key with a unique key and a not null constraint on the referencing side to enforce an (informal!) one-to-one semantics. Trying to automatically map referential constraints to higher-level concepts is where Hibernate / JPA fails. There is no easy way to automatically map what Sander is doing with his multi-column referential constraints (from the original post in this thread). This is where the "object-oriented / relational impedance mismatch" unveils fundamental problems in such mapping attempts. >> fetchArticle[List]ByPred() >> fetchArticle[List]BySucc() > > So fetchArticle would be following a to-one-relationship, and > fetchArticleList a to-many one? Yes. - X.fetchArticle means that you want to fetch the one article record that is referenced by X - Y.fetchArticleList means that you want to fetch all article records that reference Y The two are the inverse of each other. > That would be fine by me. Note, though, that for many reasons, I will remove these generated methods in jOOQ 3.0. Most importantly because it is very hard to find a good name mangling strategy that suits all. Of course, jOOQ users will always be able to extend the code generator to re-introduce these generated navigation methods. > Maybe say Set instead of List. Sets can't contain duplicates, which is a > defining property here. In relational theory, Set might be a better choice. But there are two drawbacks of choosing Set over List when fetching "child" records through foreign key navigation: 1) It is possible to have two identical "child" records in SQL. A Set would erroneously remove the duplicate. 2) SQL allows for ordering records (a non-relational SQL feature). This semantic would be lost if Set was chosen. > Some generators (notably Hibernate Tools reveng) use a plural, so that would > be fetchArticle and fetchArticles. > The resulting compactness is nice. However, generated plurals are often not > what a programmer would expect (gory details in > http://en.wikipedia.org/wiki/English_plural ). In other words, this works > only if manual intervention is easy or expected. Early versions of jOOQ also used plurals. But depending on your database naming conventions, table names may already be in a plural form. Other users may choose a language other than English for their table names. In that case, adding an "s" doesn't make sense. Then, there is the (slight) risk of introducing collisions between the ARTICLE and ARTICLES tables. This can happen between ARTICLE and ARTICLE_LIST too, of course. Which leads me back to wanting to remove these generated methods in jOOQ 3.0 Cheers Lukas
