😳 🔄 🤶🏽 JOOQ et son terrier de lapin. Comment survivre sans hibernation 👐🏼 🐛 ☪️

Dans cet article, je ne me noierai pas pour JOOQ. Je préfère Hibernate et toute la puissance JPA de Spring Data derrière. Mais l'article ne parlera pas d'eux.

Lorsque nous utilisons Hibernate et Spring Data JPA, nous n'avons pas besoin de penser aux processus internes - connaître les annotations et écrire les noms de méthode corrects dans le référentiel - ces deux monstres feront le reste pour vous. Dans le cas de JOOQ, malheureusement pour beaucoup, vous devez tendre un peu et écrire plus que findAllByUserId (Long userId) .

Qu'est-ce qu'un JOOQ?

Écrivons une simple requête SQL:

select * from countries c where c.population > 10000000;

Nous pouvons exécuter cette demande dans la console. d'accord

Nous ne nous sentons pas comme dans la console. Nous voulons que notre application envoie cette demande. Que ce n'était pas un script à usage unique et qu'il a été validé au moins pour la syntaxe. Nous le faisons via Spring Data JPA:

List<Country> findAllByPopulationAfter(Long amount);

La même demande est exécutée comme ci-dessus, mais au printemps.

Quels sont les avantages évidents de cette approche? Elle est réalisée par un framework puissant; elle valide également une demande d'erreurs. Mais la gestion des requêtes s'occupe du framework. Et nous voulons gérer complètement la demande, mais en même temps, pour que la demande soit complètement validée.
UtilisationRequete:

@Query("select c from Country c where c.population > :amount")
List<Country> findAllPopulationGreaterThan(@Param("amount") Long amount);

Un tel compromis entre SQL et DSL est également bon. Mais si nous ne voulons pas jouer avec SQL, nous serons heureux de voir quelque chose comme:

return dsl.selectFrom(COUNTRIES)
                .where(COUNTRIES.POPULATION.greaterThan(amount))
                .fetch();

Plusieurs bibliothèques conviennent à cela:

QueryDSL
JOOQ
Speedment

À propos de QueryDSL J'ai écrit il y a quelques années. Je n'ai pas creusé Speedment, mais il semble que ce soit plus qu'un simple générateur DSL, et je devrai apprendre les méthodes par lesquelles ils ont chiffré les commandes de requête SQL. En général, nous parlerons aujourd'hui de l'OJOQ.

Requêtes JOOQ

Oui, nous avons déjà vu l'une de ces requêtes ci-dessus:

return dsl.selectFrom(COUNTRIES)
                .where(COUNTRIES.POPULATION.greaterThan(amount))
                .fetch();

Qu'y a-t-il d'autre?

Par exemple, une simple requête get:

return dsl.selectFrom(Countries.COUNTRIES)
                .where(Countries.COUNTRIES.ID.eq(id))
                .fetchAny();

Ou insérez la demande:

return dsl.insertInto(Countries.COUNTRIES)
                .set(Countries.COUNTRIES.NAME, country.getName())
                .set(Countries.COUNTRIES.POPULATION, country.getPopulation())
                .set(Countries.COUNTRIES.GOVERNMENT_FORM, nameOrNull(country.getGovernmentForm()))
                .returning()
                .fetchOne();

Comme vous pouvez le voir, tout est clair, rien de plus. Mais ce n'est qu'à première vue. Découvrir à quelle profondeur ce terrier de lapin peut prendre plusieurs semaines.

Mais commençons par le début.

Oui ce sera maven

Je préfère Gradle. Mais pour une raison quelconque, les développeurs JOOQ accordent moins d'attention à Gradle, proposant d'opter pour des plugins tiers. D'accord, le projet de formation sera sur Maven. Mais si vous, cher lecteur, fouillez comme il se doit dans les profondeurs du github et êtes prêt à révéler un projet entièrement personnalisé sur Gradle - écrivez-moi et vous deviendrez co-auteur de cet article. Il en va de même pour H2 (le projet de formation sera sur PostgreSQL).

Pourquoi je n'ai pas réussi avec Gradle et H2

, Gradle. jooq-generator . H2, « » H2 , , , .

Dépendances Maven nécessaires:

<dependencies>

        <!-- Spring Starters -->
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-jooq</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-web</artifactId>
        </dependency>

        <!-- Database -->
        <dependency>
            <groupId>org.flywaydb</groupId>
            <artifactId>flyway-core</artifactId>
        </dependency>
        <dependency>
            <groupId>org.postgresql</groupId>
            <artifactId>postgresql</artifactId>
            <scope>runtime</scope>
        </dependency>

        <!-- Helpers -->
        <dependency>
            <groupId>org.apache.commons</groupId>
            <artifactId>commons-lang3</artifactId>
            <version>${commons.lang3.version}</version>
        </dependency>
        <dependency>
            <groupId>org.projectlombok</groupId>
            <artifactId>lombok</artifactId>
            <optional>true</optional>
        </dependency>

        <!--Test -->
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-test</artifactId>
            <scope>test</scope>
            <exclusions>
                <exclusion>
                    <groupId>org.junit.vintage</groupId>
                    <artifactId>junit-vintage-engine</artifactId>
                </exclusion>
            </exclusions>
        </dependency>

        <!-- JOOQ Generator -->
        <dependency>
            <groupId>org.jooq</groupId>
            <artifactId>jooq</artifactId>
            <version>${jooq.version}</version>
        </dependency>
        <dependency>
            <groupId>org.jooq</groupId>
            <artifactId>jooq-meta</artifactId>
            <version>${jooq.version}</version>
        </dependency>
        <dependency>
            <groupId>org.jooq</groupId>
            <artifactId>jooq-codegen</artifactId>
            <version>${jooq.version}</version>
        </dependency>

    </dependencies>

Spring a déjà un démarreur JOOQ qui auto-configurera le DataSource selon les paramètres spécifiés dans application.yml. Mais pour le travail complet de l'OJOQ, cela ne suffit pas. Les entités doivent être générées. Oui, oui, nous n'écrivons pas d'entités, mais nous les générons. L'approche dite de la table d'abord.

La structure d'application habituelle, axée sur l'utilisation de la base de données, ressemble à ceci:

jusqu'à la couche de service, les données transitent par l'application sous la forme d'un modèle plat (DTO). De plus, lorsque le service doit travailler avec la base de données, il convertit le DTO en une entité, l'envoie au référentiel et celui-ci le sauvegarde déjà dans la base de données. Les développeurs de JOOQ voient tout différemment:

comme on peut le voir, à JOOQ, ils ont sérieusement révisé le modèle standard et ont décidé de suivre leur propre chemin. Les différences sont importantes:

La conversion de DTO en une entité se produit déjà dans le référentiel.
Nous n'écrivons pas une entité en tant que telle. Il est écrit pour nous par le générateur JOOQ.

Déjà, cela suffit pour conclure que l'OJOQ n'est pas si simple. Une entité générée hautement personnalisable, une cartographie incompréhensible dans DTO et d'autres difficultés en effrayeront beaucoup. Mais dans les cas où il n'y a nulle part où aller, une étude ciblée de ces aspects de l'OJOQ peut sérieusement se prolonger et prendre des jours, voire des semaines. Je suis sûr que mon message vous fera gagner beaucoup de temps.

Nous couvrirons les aspects suivants de la collaboration avec l'OJOQ:

Génération d'entité.
Écriture de requêtes CRUD.
Optimisation des requêtes CRUD.
Et une autre optimisation de demande CRUD.
Mappage d'entités à l'aide de la bibliothèque JOOQ standard.
et discuter pourquoi tout cela est nécessaire.

Allons-y.

Qu'écrivons-nous?

Notre projet comportera deux entités:

Pays:

@Data
public class Country {

    private Long id;
    private String name;
    private GovernmentForm governmentForm;
    private Integer population;

    private List<City> cities;
}

Ville:

@Data
public class City {

    private Long id;
    private Long countryId;
    private String name;
}

Relation un à plusieurs. Le pays contient de nombreuses villes liées. La ville contient countryId.
La migration des voies de migration ressemble à ceci:

create table countries
(
    id              bigserial primary key,
    name            varchar(255),
    government_form varchar(255),
    population      int
);

create table cities
(
    id         bigserial primary key,
    country_id bigint,
    name       varchar(255)
);

Commençons par la génération d'entités.

Comme je l'ai dit, les entités sont générées séparément. Il y a deux façons de faire ça.

Grâce au plugin Maven.
En code Java.

Génération d'entités dans Maven

Lorsque le projet se construit, Maven démarre le générateur et génère des entités. Et vous pouvez appeler le générateur à tout moment et générer des entités. Cela est nécessaire dans les moments où, disons, la structure de la base a changé. Le plugin dans Maven ressemble à ceci:

            <!-- JOOQ Generator Plugin -->
            <plugin>
                <groupId>org.jooq</groupId>
                <artifactId>jooq-codegen-maven</artifactId>
                <version>${jooq.version}</version>
                <executions>
                    <execution>
                        <phase>generate-sources</phase>
                        <goals>
                            <goal>generate</goal>
                        </goals>
                    </execution>
                </executions>
                <configuration>
                    <jdbc>  <!--    -->
                        <driver>${db.driver}</driver>
                        <url>${db.url}</url>
                        <user>${db.username}</user>
                        <password>${db.password}</password>
                    </jdbc>
                    <generator>
                        <database>
                            <includes>.*</includes>  <!--     -->
                            <excludes>  <!--     -->
                                flyway_schema_history
                            </excludes>
                            <inputSchema>public</inputSchema>  <!--  -->
                        </database>
                        <generate>
                            <records>true</records>
                        </generate>
                        <target>
                            <!--      -->
                            <packageName>ru.xpendence.jooqexample.domain</packageName>
                            <!--  .    target. -->
                            <directory>target/generated-sources/jooq</directory>
                        </target>
                    </generator>
                </configuration>
            </plugin>

Si vous avez tout fait correctement, mettez à jour Maven et parmi les plugins vous verrez jooq-codegen.

Exécuter. Il générera des entités pour vous.

Ce sont les mêmes entités que vous utiliserez pour accéder à la base de données. Première nuisance: ils sont immuables. Autrement dit, ils sont modifiables, mais le changement de type se produit d'une manière si artificielle que cette description de processus sera tirée vers un article distinct. Par conséquent, essayez de réfléchir aux types de données au stade de la génération de la table.

Les entités semblent particulières. Voici, par exemple, la signature de la classe CountriesRecord:

public class CountriesRecord extends UpdatableRecordImpl<CountriesRecord> implements Record4<Long, String, String, Integer> {
    //...

Comme nous pouvons le voir, CountriesRecord implémente Record4, qui est tapé par 4 types. Le tableau des pays a 4 colonnes, donc Record4. Il y a 3 colonnes dans les villes, donc Record3. Pourquoi cela a été inventé, je ne sais pas. Il y a 22 enregistrements de ce type dans la bibliothèque OJOQ, Record1 ... Record22. D'où nous pouvons conclure que les capacités de JOOQ sont limitées au traitement des tables avec un maximum de 22 colonnes, mais ce n'est pas le cas. J'ai des tables avec des dizaines de colonnes et JOOQ implémente immédiatement Record. Eh bien, cela ... La

génération d'entités JOOQ en code Java ressemble à ceci:

@Component
public class AfterStartupApplicationListener implements ApplicationListener<ContextRefreshedEvent> {

    @Value("${spring.datasource.driver-class-name}")
    private String driver;

    @Value("${spring.datasource.url}")
    private String url;

    @Value("${spring.datasource.username}")
    private String username;

    @Value("${spring.datasource.password}")
    private String password;

    @Value("${jooq.generator.database.name}")
    private String databaseName;

    @Value("${jooq.generator.database.with-includes}")
    private String databaseWithIncludes;

    @Value("${jooq.generator.database.with-input-schema}")
    private String databaseWithInputSchema;

    @Value("${jooq.generator.target.package-name}")
    private String targetPackageName;

    @Value("${jooq.generator.target.directory}")
    private String targetDirectory;

    @SneakyThrows
    @Override
    public void onApplicationEvent(ContextRefreshedEvent contextRefreshedEvent) {
        new GenerationTool().run(configureGenerator());
    }

    private Configuration configureGenerator() {
        return new Configuration()
                .withJdbc(new Jdbc()
                        .withDriver(driver)
                        .withUrl(url)
                        .withUser(username)
                        .withPassword(password))
                .withGenerator(new Generator()
                        .withDatabase(new Database()
                                .withName(databaseName)
                                .withIncludes(databaseWithIncludes)
                                .withExcludes("")
                                .withInputSchema(databaseWithInputSchema))
                        .withTarget(new Target()
                                .withPackageName(targetPackageName)
                                .withDirectory(targetDirectory)));
    }
}

Dans mon cas, le générateur démarre après un démarrage complet de l'application, lorsque toutes les nouvelles migrations sont cumulées et que la base de données est à jour.

Donc, nous avons des modèles, nous avons des entités, nous avons une base. Il est temps de créer un référentiel et d'écrire des requêtes.

Créer un référentiel

Toutes les demandes passent par DslContext. Répétez le DslContext.

@Repository
@RequiredArgsConstructor
public class CountryRepository implements CrudRepository<Country> {

    private final DSLContext dsl;

}

Le référentiel est prêt.

Écriture de requêtes CRUD

Insérer

Si nous utilisions SQL, la demande d'ajout d'un autre pays serait:

insert into countries(name, government_form, population)
values (' -', 'UNITARY', 100500) returning *;

Dans JOOQ, une requête est aussi proche que possible de la syntaxe SQL:

    public Country insertValues(Country country) {
        return dsl.insertInto(Countries.COUNTRIES)  //insert into countries
                .values(country.getId(), country.getName(), country.getPopulation(), nameOrNull(country.getGovernmentForm()))  //values (? ? ? ?)
                .returning()  //returning
                .fetchOne()  //*
                .into(Country.class);
    }

Comme on le voit, rien de compliqué. Cependant, une telle demande ne nous convient pas, car dans notre cas, l'ID est généré dans la base de données et nous devons en tenir compte. Si nous écrivons quelque chose comme:

.values(null, country.getName(), country.getPopulation(), nameOrNull(country.getGovernmentForm()))

nous aurons

org.postgresql.util.PSQLException: :     "id"   NOT NULL

Cependant, si nous générions l'ID du côté de l'application, une telle demande serait un tour. Nous devrons réécrire la demande, en donnant à chaque champ une valeur spécifique. Afin que vous puissiez:

    public Country insert(Country country) {
        return dsl.insertInto(Countries.COUNTRIES)
                .set(Countries.COUNTRIES.NAME, country.getName())
                .set(Countries.COUNTRIES.POPULATION, country.getPopulation())
                .set(Countries.COUNTRIES.GOVERNMENT_FORM, nameOrNull(country.getGovernmentForm()))
                .returning()
                .fetchOne()
                .into(Country.class);
    }

Dans ce cas, nous définissons manuellement l'objet dans le champ. Cette option fonctionne assez bien, mais il y a mieux. Il serait idéal d'envoyer l'objet entier pour sauvegarde, comme cela se fait dans Spring Data JPA:

repository.save(country);

Cela pourrait être le cas. Pour ce faire, nous devons mapper notre modèle dans l'entité Record étendue et l'envoyer pour enregistrement:

    public Country insert(Country country) {
        return dsl.insertInto(Countries.COUNTRIES)
                .set(dsl.newRecord(Countries.COUNTRIES, country))  //   
                .returning()
                .fetchOptional()
                .orElseThrow(() -> new DataAccessException("Error inserting entity: " + country.getId()))
                .into(Country.class);
    }

Cette méthode est la plus simple et la plus compréhensible dans les cas où nous n'avons pas besoin de configurer le mappage. Mais le réglage de la cartographie sera plus bas.

Comme nous l'avons remarqué, cette requête renvoie l'entité entière. Vous pouvez déterminer exactement ce que vous devez retourner dans la méthode fetch (). Cela ressemble à ceci:

    public Long insertAndReturnId(Country country) {
        return dsl.insertInto(Countries.COUNTRIES)
                .set(dsl.newRecord(Countries.COUNTRIES, country))
                .returning(Countries.COUNTRIES.ID) //  Record    - id
                .fetchOptional()
                .orElseThrow(() -> new DataAccessException("Error inserting entity: " + country.getId()))
                .get(Countries.COUNTRIES.ID); // id
    }

Un peu encombrant, mais, encore une fois, avec quoi comparer.

Nous écrirons le reste des méthodes CRUD.

Mise à jour

Requête SQL:

update countries
set name            = '',
    government_form = 'CONFEDERATE',
    population      = 100500
where id = 1
returning *;

Demande JOOQ:

    public Country update(Country country) {
        return dsl.update(Countries.COUNTRIES)
                .set(dsl.newRecord(Countries.COUNTRIES, country))
                .where(Countries.COUNTRIES.ID.eq(country.getId()))
                .returning()
                .fetchOptional()
                .orElseThrow(() -> new DataAccessException("Error updating entity: " + country.getId()))
                .into(Country.class);
    }

Sélectionner

Une requête en SQL serait:

select *
from countries c
where id = ?;

Dans JOOQ, la requête se présentera en conséquence:

    public Country find(Long id) {
        return dsl.selectFrom(Countries.COUNTRIES) //select * from countries
                .where(Countries.COUNTRIES.ID.eq(id))  //where id = ?
                .fetchAny()  // ,    
                .into(Country.class);
    }

Supprimer

Il y a des demandes dans lesquelles nous n'avons rien à retourner. Ces requêtes renvoient le nombre de lignes affectées. En suppression, nous n'avons rien à retourner, mais les informations que nous recevons nous seront toujours utiles.

    public Boolean delete(Long id) {
        return dsl.deleteFrom(Countries.COUNTRIES)
                .where(Countries.COUNTRIES.ID.eq(id))
                .execute() == 1;
    }

Nous supprimons une ligne. Ainsi, la requête SQL retournera quelque chose comme:

1 row affected in 5 ms

Ayant reçu une telle réponse, nous savons avec certitude que la ligne a été supprimée. Ce sera suffisant pour déclarer l'opération réussie.

Ce n'était pas un conte de fées. C'était juste un lubrifiant. Utilisation d'un mappeur standard pour le mappage fin d'une entité dans Record et vice versa

"D'accord," dites-vous, lecteur, "où est un à plusieurs, emoe?" Quelque chose que je n'ai pas vu le moment où le pays grandit avec une multitude de villes. »

Et vous aurez raison. Ce n'est pas Hibernate; ici, vous devez le faire manuellement. Tout ce que vous devez faire est d'obtenir une liste des villes pour lesquelles id = country.getId (). J'ai déjà montré la méthode into (), qui utilise un mappeur normal pour mapper Record dans une entité. Mais JOOQ a une méthode map () supplémentaire qui nous permet de faire tout ce que nous voulons avec Record. Examinons ses fonctionnalités et ajoutons l'ajout de villes:

    public Country find(Long id) {
        return dsl.selectFrom(Countries.COUNTRIES)
                .where(Countries.COUNTRIES.ID.eq(id))
                .fetchAny()
                .map(r -> {
                    Country country = r.into(Country.class);
                    country.setCities(cityRepository.findAll(Cities.CITIES.COUNTRY_ID.eq(country.getId())));
                    return country;
                });
    }

Comme nous le voyons, maintenant nous mappons d'abord l'enregistrement dans le pays, puis nous faisons une autre demande dans les villes, nous obtenons toutes les villes pour ce pays et les définissons en substance.

Mais il peut y avoir des dizaines de tels ensembles, ce qui signifie qu'il peut y avoir des dizaines de demandes. Et décrire ces requêtes directement dans la méthode, c'est comme ça. La bonne solution consiste à écrire un mappeur distinct et à y placer toutes ces demandes.

@RequiredArgsConstructor
@Component
public class CountryRecordMapper implements RecordMapper<CountriesRecord, Country> {

    private final CityRepository cityRepository;

    @Override
    public Country map(CountriesRecord record) {
        Country country = record.into(Country.class);
        country.setCities(cityRepository.findAll(Cities.CITIES.COUNTRY_ID.eq(country.getId())));
        return country;
    }
}

La requête ressemblera maintenant à ceci:

    public Country findWithCustomMapper(Long id) {
        return dsl.selectFrom(Countries.COUNTRIES)
                .where(Countries.COUNTRIES.ID.eq(id))
                .fetchAny()
                .map(r -> countryRecordMapper.map((CountriesRecord) r));
    }

Il est plus concis et ne contient pas de logique supplémentaire.

Ok, nous avons appris à mapper Record dans une entité, mais qu'en est-il du réglage fin du mappage d'une entité dans Record?

Jusqu'à présent, nous avons cette conception:

.set(dsl.newRecord(Countries.COUNTRIES, country))

Déjà bon, mais que se passe-t-il si nous devons cartographier spécifiquement un champ? Par exemple, nous avons LocalDateTime et un générateur pour PostgreSQL comme Timestamp a généré un OffsetDateTime. Dans ce cas, le champ ne sera tout simplement pas mappé et non enregistré dans la base de données. Pour de tels cas, nous aurons besoin d'un autre mappeur qui fera de même, mais dans la direction opposée.

Oui, pour chaque mappeur, nous avons un mappeur

Il s'appelle ainsi. Écrivons son héritier.

@Component
@RequiredArgsConstructor
public class CountryRecordUnmapper implements RecordUnmapper<Country, CountriesRecord> {

    private final DSLContext dsl;

    @Override
    public CountriesRecord unmap(Country country) throws MappingException {
        CountriesRecord record = dsl.newRecord(Countries.COUNTRIES, country);
        record.setPopulation(-1);
        return record;
    }
}

Insérer avec son application ressemblera à ceci:

    public Country insertWithUnmapper(Country country) {
        return dsl.insertInto(Countries.COUNTRIES)
                .set(countryRecordUnmapper.unmap(country))
                .returning()
                .fetchOptional()
                .orElseThrow(() -> new DataAccessException("Error inserting entity: " + country.getId()))
                .into(Country.class);
    }

Comme nous le voyons, aussi tout à fait.

Conclusions et conclusions

Personnellement, j'aime plus Hibernate. Probablement, pour 90 +% des applications son utilisation sera plus justifiée. Mais si vous, le lecteur, souhaitez contrôler chaque demande, JOOQ ou une autre bibliothèque similaire vous convient mieux.

Comme toujours, je poste le projet de formation. Il est allongé ici .

JOOQ et son terrier de lapin. Comment survivre sans hibernation