Hi Thomas,

I'm sorry for the delay. This message slipped under my radar

2017-03-09 15:49 GMT+01:00 Thomas GILLET <[email protected]>:

> My usual advice here is to do what also some of the JPA advocates advise
>> to do: Mix both worlds. Write the query with jOOQ, but execute and map it
>> with JPA:
>> https://www.jooq.org/doc/latest/manual/sql-execution/
>> alternative-execution-models/using-jooq-with-jpa/using-
>> jooq-with-jpa-entities
>
>
> I had forgotten this “native query” stuff. I can indeed use JPA with SQL,
> so with jOOQ!
>

Yes, there's a thin line when to stick with the SQL paradigm, and when to
switch to the ORM paradigm. I like to link to this article here by Mike
Hadlow:
http://mikehadlow.blogspot.ch/2012/06/when-should-i-use-orm.html

He included a helpful diagram:

[image: Inline-Bild 1]

> Glad you told me. I was starting to wonder how to use jOOQ to generate
> JPQL queries...
>

Don't! :)

In my opinion, once you start querying (entities or tuples (what those
folks call "projections")), JPQL is so primitive that you'll fight the
language limitations all the time, wishing you had switched to SQL from the
beginning.

A long time ago, I thought JPQL at least doesn't bypass first and second
level caches and somehow magically joins cached entities to actual
entities. But it doesn't. So, I really don't see any benefit at all in
using a JPQL (or Criteria) Query. But again, that's my opinion.


> In theory, and in my opinion, the perceived impedance mismatch is only a
>> SQL language implementation detail, or missing feature:
>>
> https://blog.jooq.org/2015/08/26/there-is-no-such-thing-as-
>> object-relational-impedance-mismatch/
>
>
> Interesting thoughts… This will make me think for a while…
>

Looking forward to your thoughts :)


> Oh oh... That's a recursive tree structure. […] you could work around
>> things by tricking and using recursive SQL, and then materialising the tree
>> only in the client.
>
>
> Errr… what? That’s just a very simple tree… Three tables, two relations
> (one 1-1 and one 1-N). In what way is it recursive?
> I also don’t get the recursive SQL… I know how it works for a hierarchy of
> elements of the same type (i.e inside one table), but with 3 different
> tables, without any self-reference… Am I missing something?
>
> Or maybe you misunderstood my schematic? That would explain your
> enthusiasm for this ;) because modelling an actual recursive tree, *that*
> would be more of a challenge…
>

OK, I misunderstood.

When you say “bulk”, do you mean batch operations? I was under the
> impression that batches cannot return results…
> Also this definitely needs deferred constraints to work, right?
>

No, I try to clearly distinguish between the terms "bulk" and "batch"
(they're heavily overloaded in the blogosphere, unfortunately).

- Bulk: Several rows per statement. This mostly optimises algorithms in the
database.
- Batch: Several statements per request. This mostly optimises network
traffic to the database.

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/d/optout.

Reply via email to