> Good point. But maybe jOOQ could still support inheritance-mapping > when only single-inheritance is used in the database.
I prefer not to implement (and maintain) such special cases. If there is support for RDBMS-inheritance in jOOQ, then it should be consistent for a maximum number of use cases. In my opinion, ignoring inheritance and treating the two tables as if there were no link is better than just supporting single inheritance. I feel I could get this very wrong, if not properly understood. > Wouldn't it be possible to work around this by letting the 'user > facing' types (Cities, CitiesRecord, etc.) be interfaces instead of > classes? That, in turn, is a very good idea, even if it will cause a major compatibility break. But it allows for multiple inheritance by mixin-API design. That's possible both with the "implements" clause, as well as with the "extends" clause for generics <R extends ... & I1 & I2>. In any case, having "user facing" types being interfaces rather than classes would allow for many other features that can be hidden behind those interfaces. To name a few: - Aliasing could be heavily improved when fields were accessed via generated methods, instead of static singleton field instances (https://sourceforge.net/apps/trac/jooq/ticket/117). The Field.as(String) method could return the table type itself instead of returning an anonymous table. - Various jOOQ internals can be hidden behind interfaces. Currently, there is some potential for API leak (https://sourceforge.net/apps/trac/jooq/ticket/686). Client code can call methods from AbstractQueryPart and similar classes. - A lot more... I have filed this idea as https://sourceforge.net/apps/trac/jooq/ticket/688
