Hello, > It would be nice to be able to write a query like this: > > .where(user.orgUnit.location.language.isoCode.equal( 'en' ) )
Yes, this HQL-like navigation style would indeed be quite useful in 1-1 and 1-n relationships. Let's track this idea as #1502: https://sourceforge.net/apps/trac/jooq/ticket/1502 > jOOQ should then generate the necessary join in the SQL dialect for the > database. One important feature would be that joins are reused: > > .where(user.orgUnit.location.language.isoCode.equal( 'en' ) ) > .and( user.orgUnit.location.language.validTo.isNull() > or user.orgUnit.location.language.validTo.greaterThan(now()) ) > > Is that possible? I can imagine that it is possible in principle. But I see several immediate problems: 1. When using fields on the tables (instead of methods), all of those objects have to be somehow created with a relevant state. In other words, user.orgUnit.location is not the same as orgUnit.location. The two will have to result in different joins. That is a (prohibitive) lot of state to keep in memory and to initialise, as all the possible foreign key navigation paths would have to be initialised. With methods, it might work, as join paths could be created "ad-hoc": user.orgUnit().location().language().isoCode.equal("en") 2. The naming for such methods would be tricky in the case of multi-column foreign keys. 3. Should this generate INNER or OUTER JOINs? I guess outer joins would be more general. This is somehow going into what Hibernate has been doing for a long time. QueryDSL seems to support this kind of functionality using the notion of "paths". Probably, QueryDSL doesn't natively support paths (i.e. transforming them into joins) but renders those paths directly into HQL / JPQL, which in turn supports them. Do you see any other obstacles? Or design hints? Cheers Lukas
