Hi Bernd, Thanks for sharing all of this. Very interesting insight, also for future jOOQ features.
On Thu, Mar 28, 2024 at 4:36 PM 'Bernd Huber' via jOOQ User Group < [email protected]> wrote: > Hello Lukas, > > yes, i would use them, but the jOOQ's records are representing the > Database-Layer and each jOOQ record represents a Table. For example: > > AuthorRecord represents Table Product > BookRecord represents Table Book > > In a SaaS Application we typically need to have an intermediate Layer > (DTOs / Domain Transfer Objects) that are containing relationships data, > and this Layer is between the REST-Endpoints and the Database-Layer. [...] > Just curious. You've probably explored and rejected this option. What about using database views for this? In general, I feel like all of what you're describing is exactly what Oracle 23c introduced with their JSON-Relational Duality Views: https://docs.oracle.com/en/database/oracle/oracle-database/23/jsnvu/overview-json-relational-duality-views.html#GUID-CE7227BF-B4AF-4024-A578-ED52795F4525 An incredible feature which I plan to support in jOOQ: https://github.com/jOOQ/jOOQ/issues/14912 At first, jOOQ support would primarily consist in generating Java POJOs for the JSON data, possibly with Jackson annotations to help third parties. And then, also explore how it could be emulated on other RDBMS. Even without Oracle's feature, views could help with: - Reducing the visibility of certain columns - Reusing both jOOQ-generated POJOs and Records (at least, if you can add the constraint information to the views: https://www.jooq.org/doc/latest/manual/code-generation/codegen-advanced/codegen-config-database/codegen-database-synthetic-objects/ ) I've also thought about dirty tracking in generated POJOs in the past, though rejected it so far because of the substantial design effort if implemented on its own. POJOs are meant to be dependency free (from jOOQ), so how to implement all this logic without too much repetition? Perhaps, a AbstractDirtyTrackingPojo base class that is generated into generated code? Or generate duplicate tracking code nonetheless in each method? But in a bigger context, the feature becomes more re-usable, so let's add a new feature request to at least track the idea for the future: https://github.com/jOOQ/jOOQ/issues/16534 Comparable requests have been rejected so far in Lombok (despite this being a prime use-case for Lombok!): https://github.com/projectlombok/lombok/issues/1212 > Also it is important to separate DTOs from the Database-Layer, because in > the DTOs we can decide which fields should be hidden from the frontend > (password-field in the User-Table for example). > Again, views could help here. Also, jOOQ 3.20 will finally support hidden fields: - https://github.com/jOOQ/jOOQ/issues/13411 - https://www.jooq.org/doc/3.20/manual/sql-building/column-expressions/hidden-columns/ Password columns are exactly a use-case for this. > In my implementation i did use the Jooq Generated Pojos and the > self-written DTOs extend a common base class (AbstractDTO), > so they both save the modified fields. That way in the DAO-Abstraction i > can map the changed-fields correctly from the DTOs to the Jooq-Pojos, > and only send the modified fields to the database in the Update-Case. In > the Insert-Case all fields are sent to the database. > Is it possible to share your AbstractDTO? Obviously, you might not be able to do that, but it's worth asking. -- 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]. To view this discussion on the web visit https://groups.google.com/d/msgid/jooq-user/CAB4ELO6wmA6ZvnKOpCqpuopRF4dfsuiVFC8M0swajJcsZzu-5w%40mail.gmail.com.
