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.

So for example. The Frontend sends a REST POST Request to the backend to 
insert data. This POST Request contains the data as JSON and
represented by the DTO, so it can contain all relevant data to insert an 
Author with his Books in one REST-Request instead of many separate 
REST-Request 
and we can also guarantee Transaction-Safety (either the complete 
REST-Request is inserted into the database or we rollback). This JSON would 
look like this:

{
  "name": "George Orwell",
  books: [{
    "title": "1984"
  }]
}

Now the REST-Layer will parse this JSON and create the AuthorDTO from it. 
While Parsing the JSON the Setter-Methods of the AuthorDTO are called.
The AuthorDTO contains relationships to other DTOs as well.

public class AuthorDTO {
  
  private String name; 

  private String birthyear;

  private List<BookDTO> books;
}

When the DTOs are Plain Pojos, we will loose the information which of the 
fields have really be given by the frontend to the backend in the JSON.
After JSON-Derserialization took place we can not know it anymore.

When we later convert the DTOs to the Jooq-Records, we need to have this 
information present. 

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).

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.

That way the backend-developers hopefully do not need to fetch records from 
the database and send them to the frontend, only for the frontend
to change exactly one field to send the update back to the backend 
(Roundtrip).

Instead the Frontend can fire-and-forget sent the Update to the backend and 
the one field in the database is updated, without the Frontend needing
to know the complete model as it exists in the database.

Thats the benefit from having the modified-fields and pushing them trough 
all the layers (REST, DTO, Database)


[email protected] schrieb am Donnerstag, 28. März 2024 um 14:04:48 UTC:

> What keeps you from just using jOOQ's records?
>
> On Thu, Mar 28, 2024 at 11:53 AM 'Bernd Huber' via jOOQ User Group <
> [email protected]> wrote:
>
>> Hello guys,
>>
>> this is not directly jOOQ related, but maybe someone here has already had 
>> this problem, and has some input to share.
>>
>> I posted this on stackoverflow:
>> - 
>> https://stackoverflow.com/questions/78237587/java-pojos-modified-fields-and-change-detection
>>
>> It is a bit related to the following jooq blog post:
>> - 
>> https://blog.jooq.org/orms-should-update-changed-values-not-just-modified-ones/
>>
>> I needed to write a common `AbstractDTO` class, that all the 
>> jooq-generated DTOs and my own DTOs need to extend from, because i needed 
>> "modified-fields" detection. I have described it in my stackoverflow post.
>>
>> We have two cases when we send data to the database:
>> - Insert: send and validate everything we have in the model
>> - Update: only send and validate modified/touched stuff in the model.
>>
>> Java does not seem to have a default mechanism to detect if a field in a 
>> pojo has ever been modified or still has its default (never touched).
>>
>> Its not urgent to me, but if someone reads it and instantly knows a 
>> library or tool for something like this, give me a call ;)
>>
>> -- 
>> 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/0624283a-e9a5-40d3-8548-c00141fca706n%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/jooq-user/0624283a-e9a5-40d3-8548-c00141fca706n%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
>

-- 
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/d8e94b02-a7dc-4324-8f49-7e52da6988ccn%40googlegroups.com.

Reply via email to