Hello Lukas, happy, that the ideas are interesting :)
i only used mariadb and mysql in my developers career. I will take a look at those capacities of Views and how they could help with this relational datas/tree-structure that i call DTOs here. They could really often be a good basis for the typical relationships between the database-tables. Mostly the DTOs are almost always a mapping of the already existing relationships between database tables, and they correspond with what Hibernate does with the Relationshop-Annotations (@OneToMany, @ManyToOne, ...) So i think your approach to already let the definition be made on the database-level is interesting! I would find it awesome if such schema-defined JSON-Tree Structures would result in Jooq generated Code for those, that would already contain the relationships! I wonder if this would support all cases (READ, INSERT, UPDATE, DELETE) on elements of this JSON, but i guess it would be easy, as the database only needed to save the JSON then. --- thanks for the other links, i will check them out! --- sure i can share the AbstractDTO. - https://github.com/funkrusher/fk-framework-quarkus-jooq/blob/main/fk_core/src/main/java/org/fk/core/dto/AbstractDTO.java Its like this: - The Core-Project contains the AbstractDTO - The Database-Project contains the Jooq-Codegen and depends on the Core-Project only for this AbstractDTO (needs nothing else) - The Product-Project contains the Business-Logic and depends on the generated Jooq-Code of the Database-Project, and also on the Core-Project for Basic-Stuff (DAO-Abstraction, ...) lukas...@gmail.com schrieb am Donnerstag, 4. April 2024 um 07:32:50 UTC: > 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 < > jooq...@googlegroups.com> 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 jooq-user+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jooq-user/ae92b2df-9d62-480d-ba63-b85ec549c1fdn%40googlegroups.com.
