>> Possibly, it would be wiser to add a generic fetch(ForeignKey) and
>> fetchOne(ForeignKey) method, that allows for navigating data through foreign
>> keys...
>
> Definitely.
In fact, the projected API will include (simplified):
---------------------------------------------------------------
interface TableRecord<R extends TableRecord<R>> {
<O extends UpdatableRecord<O>> O fetchParent(ForeignKey<R, O> key)
throws DataAccessException;
}
interface UpdatableRecord<R extends UpdatableRecord<R>> {
<O extends TableRecord<O>> O fetchChild(ForeignKey<O, R> key)
throws InvalidResultException, DataAccessException;
<O extends TableRecord<O>> Result<O> fetchChildren(ForeignKey<O,
R> key) throws DataAccessException;
}
interface ForeignKey<R extends Record, O extends Record> {
O fetchParent(R record) throws DataAccessException;
Result<O> fetchParents(R... records) throws DataAccessException;
Result<O> fetchParents(Collection<? extends R> records) throws
DataAccessException;
Result<R> fetchChildren(O record) throws DataAccessException;
Result<R> fetchChildren(O... records) throws DataAccessException;
Result<R> fetchChildren(Collection<? extends O> records) throws
DataAccessException;
}
---------------------------------------------------------------
The notions of "fetch()" and "fetchOne()" aren't unambiguously
applicable to directed foreign key navigation. Better terms that are
frequently used in relational literature and examples are "parent"
(referenced record) and "child" (referencing record).
I'm open to alternative naming schemes, as this is something new to the jOOQ API
> I have an N:M join table that links predecessor to successor articles.
> So it has two foreign keys, one to the predecessor article, one to the
> successor article. And it would make a huge difference which of the two FKs
> I'm following!
The current implementation of jOOQ-codegen would generate something like:
fetchArticle[List]ByPred()
fetchArticle[List]BySucc()
So, disambiguation is already implemented - at least for single-column
foreign keys.
> In other tables, I'm having stuff like "company-specific relationships". Say,
> each article has an additional company field, and the predecessor-successor
> article would have three fiels:
> company
> pred
> succ
> The predecessor FK would consist of company&pred, the successor FK of
> company&succ. That's a case of overlapping FKs.
Yes. That's where jOOQ-codegen will probably fail, as of version
2.6.x. This will be unambiguous, once the new API is published, where
you can fetch parents / children, by following specific foreign key
relationships.
Cheers
Lukas
