> > * Is this general approach the right one? > Do also check for unique constraints on the foreign key. It's not a widely adopted practice, but if you do encounter one, you'll know it's a 1-1 relationship (where 1 means 0..1). Other than that, I mean, it's a heuristic. You won't have any guarantees about 1-1 relationships if they're not enforced with a unique key. As with any heuristics: Good luck! :)
> * is it correct to be using fk.key.fields and fk.inverseKey.fields the way > I am? > Why wouldn't it be? > * is the assumption that fk.key.fields is ordered equivalently to > fk.inverseKey.fields justified? > Yes, there's no reason to shuffle these. We're just swapping keyFields and fields of the ForeignKey, as well as the tables, of course. > * does JOOQ have a fancier type of join where I don't really need to > enumerate the fields in the on() anyway? (Assuming there is only 1 FK > between the tables) > onKey(ForeignKey) would probably help? > * why doesn't 'eq()' work the way I am trying to use it? (I understand it > could be a Kotlin thing) > Well, the type is Field<*>, and as with any wildcards, these prevent comparisons / method calls like these. Just like you cannot add anything to a MutableList<*>, because you don't know what * stands for. In Java, the usual workaround is to use raw types here. In Kotlin, I guess you could unsafe cast both fields to Field<Any?>. But this will be unnecessary with onKey() -- You received this message because you are subscribed to the Google Groups "jOOQ User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jooq-user/CAB4ELO7ghpnY16_koAUt-B6bJDGvJKtTKWyV20SoQq8%3D1ZFivg%40mail.gmail.com.
