Hi Joachim,
I'll keep my responses short, as this thread is getting hard to track :-)
> Now I have to show how little of Jooq I've seen yet ;-) , but anyway:
> Is there a workaround for code that uses these fetch{Entity} and
> fetch{Entity}List calls?
Yes, you will be able to navigate the generated ForeignKey objects in
both directions. You can check out the API code here:
https://github.com/jOOQ/jOOQ/blob/master/jOOQ/src/main/java/org/jooq/ForeignKey.java
This was introduced with #2044
https://github.com/jOOQ/jOOQ/issues/2044
> I'm seeing the laziness issue.
Not sure what you mean. This discussion went on in another thread.
Here's a summary:
- jOOQ will NEVER fetch anything other than what you explicitly tell
it to fetch through the DSL API.
- jOOQ will ALWAYS fetch records first (in other words: tables)
- jOOQ will ONLY THEN optionally transform records into POJOs
according to rules that may be enhanced in the future. These rules are
not yet defined.
So I don't see any laziness problems. Client code is responsible to
spell out all the necessary JOIN clauses, predicates, etc. to get the
tables they need. Going farther than that wouldn't be within jOOQ's
mission anymore.
> I'd not recommend using the same annotations as JPA.
> Aspect 1: Principle of least surprise. People with a JPA background
> might expect Jooq to do lazy loading if they see the same
> annotations being used.
I haven't fully evaluated that yet.
> Aspect 2: Coexistence. It would be desirable to allow the same
> Pojo class to work in JPA and with Jooq. If there's a case where
> Jooq usage would need different annotation values than JPA usage,
> you can't reuse a Jooq class in a JPA context or vice versa. I
> don't know whether such a case exists, but it might come up as
> JPA evolves, so I'd want to avoid that.
That might be true.
>> I think that - if jOOQ were to go down that road - the POJO
>> should be considered part of the "Java domain", whereas the
>> org.jooq.Record should be considered part of the "RDBMS domain".
>
> I'm not sure whether that's a good idea.
Anyway, that ship has sailed.
> Jokes aside, the more interesting question (for me) is whether
> the relational links between Records should really be handled
> differently than those between pojos.
Records: 1-1 mapping between SQL and Java (like ActiveRecords)
POJOs: Arbitrary user code
It's the old story of the ORM impedance mismatch, to try to make them
work the same way.
>> two consecutive executions of the same / a similar query
>> would have to produce identical records.
>
> Only if you have a guarantee that identity inside the
> RDBMS maps to identity inside the JVM.
> Which, of course, it doesn't. Not even with a fully
> normalized schema where every table has a PK. Does Jooq
> even want to guarantee this kind of equivalence, across
> transactions? DB connections/sessions? JVMs?
jOOQ does not care about what you called object identity. jOOQ will
always treat record equality according to what SQL understands by row
value expression equality. The concept of identity is not involved in
this discussion.
Summary:
- Laziness is not a relevant topic for jOOQ as jOOQ users fully
control their SQL.
- Adding improved mapping from records "into" POJOs needs more
thinking. This is a low prio to me, as it is hard to get this right.
I'm waiting for user contributions / concrete suggestions in that
area, for now.
- Record equality is well-defined in jOOQ through row value expression
equality, not through identity
Cheers
Lukas
--
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].
For more options, visit https://groups.google.com/groups/opt_out.
