> Wow, it seems that interface idea was even better than i thought ;) I now wonder why I hadn't thought of it from the beginning...
> There's another (wild) idea related to interfaces that crossed my mind > when i was thinking about inheritance and interfaces. In absence of > real "inheritance" functionality, many databases have multiple tables > that follow the same "base column pattern", for example: > > id int primary key, > creation_time timestamp, > modification_time timestamp, > creator_uid int, > mutator_uid int Yes, that's a very common pattern. I had actually thought about this recently in an entirely different context. Apart from this pattern, there is also the change history pattern, audit pattern, and various other ones that are implemented time and again. Intuitively, I feel that these features are out of scope for jOOQ, though. Maybe there should be another artefact called jooq-tools built on top of jOOQ, in order to extend jOOQ for these frequently used patterns. Such a jooq-tools project will then also contain DDL statements in order to create the necessary triggers / columns / change-history tables, etc, according to best practices for these use-cases. A separate project would keep the core basic and low-level. > .. etc. Sometimes it would be nice to be able to write code that is > able to treat these base columns of records of any of these tables the > same way. Currently that is very hard to do with jOOQ because all > generated Record classes directly extend UpdatableRecordImpl, which - > of course- doesn't have any getter or setter methods for these > columns. >From my experience, the database is the best place to handle these items. With identity columns and triggers, you can easily insert/update creation/modification time/users. But I agree, if the RDBMS of choice does not support triggers, "injected" interfaces might become useful. The above jooq-tools project would then heavily rely on such interface-injection... In any case, looks like there is some work ahead, in jOOQ :-)
