Comment Spring Data Jdbc joint les tables

Dans cet article, nous verrons comment Spring Data Jdbc crée des requêtes SQL pour récupérer des entités associées.



Le message est conçu pour les programmeurs novices et ne contient pas de choses super délicates.

J'invite tout le monde à la journée de démonstration du cours en ligne «Java Developer. Professionnel " . Dans le cadre de l'événement, je vous parlerai en détail du programme du cours, ainsi que de répondre à vos questions.

Une partie de la solution comme Hibernate est utilisée, car c'est très pratique pour travailler avec des objets imbriqués.



Par exemple, il existe une classe RecordPackage, l'un des champs de cette classe est une collection d'objets enfants (ou imbriqués): les enregistrements.



Si vous utilisez Jdbc, vous devrez écrire beaucoup de code de routine. Peu de gens l'aiment, ce qui explique en partie pourquoi ils utilisent Hiberhate.



Avec Hibernate, vous pouvez appeler une méthode à la fois pour obtenir un RecordPackage avec tous ses enregistrements enfants.



D'une part, je veux utiliser une méthode pour obtenir l'objet entier, et d'autre part, je ne veux pas jouer avec le monstre Hibernate.



Spring Data Jdbc vous permet de tirer le meilleur parti de ces deux mondes (ou du moins quelque chose d'acceptable).



Prenons deux cas:

• relation un-à-plusieurs
• relation individuelle

Ce sont ces connexions qui sont le plus souvent rencontrées dans la pratique.



Le code complet des exemples peut être trouvé sur GitHub, ici je ne donnerai que le minimum.

Tout d'abord, il convient de noter que Spring Data Jdbc n'est pas un outil magique pour résoudre un problème. Il a certainement ses inconvénients et ses limites.

Cependant, pour un certain nombre de tâches typiques, c'est une solution parfaitement adaptée.

Relation un-à-plusieurs

Comme exemple concret, vous pouvez considérer: l'en-tête d'un paquet de certaines données et les lignes de données incluses dans ce paquet. Par exemple, fichier est un package et les lignes de fichier sont des lignes de données qui entrent dans ce package.



La structure des tableaux est la suivante:

create table record_package
(
    record_package_id bigserial    not null
        constraint record_package_pk primary key,
    name              varchar(256) not null
);

create table record
(
    record_id         bigserial    not null
        constraint record_pk primary key,
    record_package_id bigint       not null,
    data              varchar(256) not null
);

alter table record
    add foreign key (record_package_id) references record_package;

deux tableaux: record_package(en-tête d'un certain paquet) et record(enregistrements inclus dans le paquet).

Comment cette relation est affichée dans le code java:

@Table("record_package")
public class RecordPackage {
    @Id
    private final Long recordPackageId;
    private final String name;

    @MappedCollection(idColumn = "record_package_id")
    private final Set<Record> records;
….
}

Ici, nous nous intéressons à la définition d'une relation un-à-plusieurs. Ceci est codé à l'aide d'une annotation @MappedCollection.



Cette annotation a deux paramètres:



idColumn - le champ par lequel la connexion est établie

; keyColumn - le champ par lequel les enregistrements de la table enfant sont classés.



Cette commande mérite d'être mentionnée séparément. Dans cet exemple, peu nous importe dans quel ordre les enregistrements enfants seront insérés dans la table des enregistrements, mais dans certains cas, cela peut être important. Pour un tel classement, la table record aura un champ comme record_no, c'est ce champ qui devra être écrit dans la keyColumn de l'annotation MappedCollection. Lorsque vous exécutez l'insertion, Spring Data Jdbc génère les valeurs de ce champ. En plus de l'annotation, Set <Record >devra être remplacé par List<Record >, ce qui est assez logique et compréhensible. La séquence de lignes enfants explicitement spécifiée sera prise en compte lors de la formation de la sélection, mais nous y reviendrons plus tard.



Nous avons donc identifié les connexions et sommes prêts à l'essayer.



Nous créons des entités associées et les récupérons depuis la base:

  var record1 = new Record("r1");
  var record2 = new Record("r2");
  var record3 = new Record("r3");

   var recordPackage = new RecordPackage( "package", Set.of(record1, record2, record3));
   var recordPackageSaved = repository.save(recordPackage);

   var recordPackageLoaded = repository.findById(recordPackageSaved.getRecordPackageId());

Notez que nous n'avons besoin d'appeler qu'une seule méthode repository.findByIdpour obtenir une instance RecordPackageavec une collection d'enregistrements remplie.



Bien sûr, nous nous intéressons au type de requête SQL qui a été exécutée pour obtenir la collection imbriquée d'enregistrements.



Comparé à Hibernate, Spring Data Jdbc est bon pour sa simplicité. Il peut être facilement débogué pour révéler les principaux points.



Après une petite enquête dans le package org.springframework.data.jdbc.core.convert , nous trouvons la classe DefaultDataAccessStrategy . Cette classe est chargée de générer des requêtes SQL basées sur les informations de classe. Maintenant, dans cette classe, nous nous intéressons à la méthode

Iterable <Object> findAllByPath

Et plus précisément la ligne:

String findAllByProperty = sql(actualType) 
    .getFindAllByProperty(identifier, path.getQualifierColumn(), path.isOrdered());

Ici, la requête SQL requise est extraite du cache interne.



Dans notre cas, cela ressemble à ceci:

SELECT "record"."data" AS "data", "record"."record_id" AS "record_id", "record"."record_package_id" AS "record_package_id" 
FROM "record" 
WHERE "record"."record_package_id" = :record_package_id

Tout est clair et prévisible.



À quoi cela ressemblerait-il si nous utilisions l'ordre des enregistrements dans la table enfant? De toute évidence, une commande serait requise.



Passons à la classe BasicRelationalPersistentProperty du package org.springframework.data.relational.core.mapping. Cette classe a une méthode qui détermine s'il faut ajouter un ordre par à la requête ou non.

	
public boolean isOrdered() {
  return isListLike();
}

et

private boolean isListLike() {
  return isCollectionLike() && !Set.class.isAssignableFrom(this.getType());
}

isCollectionLike vérifie que nous avons vraiment une "collection" (y compris un tableau).

Et à partir de la condition ! Set.class.isAssignableFrom (this.getType ()); il devient clair que Set n'est pas utilisé par hasard, mais pour exclure le tri inutile. Et un jour, nous utiliserons intentionnellement List pour activer le tri.



Je pense qu'un-à-plusieurs est plus ou moins clair, passons au cas suivant.

Relation individuelle

Disons que nous avons une telle structure.

create table info_main
(
    info_main_id bigserial    not null
        constraint info_pk primary key,
    main_data    varchar(256) not null
);

create table info_additional
(
    info_additional_id bigserial    not null
        constraint additional_pk primary key,
    info_main_id       bigint       not null,
    additional_data    varchar(256) not null
);

alter table info_additional
    add foreign key (info_main_id) references info_main;

Il existe une table avec des informations de base sur un certain objet (info_main) et des informations supplémentaires (info_additional).



Comment cela peut-il être représenté dans le code:

@Table("info_main")
public class InfoMain {
    @Id
    private final Long infoMainId;
    private final String mainData;

    @MappedCollection(idColumn = "info_main_id")
    private final InfoAdditional infoAdditional;
…
}

À première vue, cela ressemble au premier cas un-à-plusieurs, mais il y a une différence. Cette fois, l'enfant est vraiment un objet, pas une collection comme dans le cas précédent.



Le code de test ressemble à ceci:

  var infoAdditional = new InfoAdditional("InfoAdditional");

  var infoMain = new InfoMain("mainData", infoAdditional);

  var infoMainSaved = repository.save(infoMain);
  var infoMainLoaded = repository.findById(infoMainSaved.getInfoMainId());

Voyons quelle expression sql est générée cette fois. Pour ce faire, nous allons dénicher la méthode findById à l'endroit:



Package org.springframework.data.jdbc.core.convert class DefaultDataAccessStrategy . Nous connaissons déjà cette classe, maintenant nous nous intéressons à la méthode.

public <T> T findById(Object id, Class<T> domainType)

On voit que la requête suivante est récupérée du cache:

SELECT "info_main"."main_data" AS "main_data", "info_main"."info_main_id" AS "info_main_id", "infoAdditional"."info_main_id" AS "infoadditional_info_main_id", "infoAdditional"."additional_data" AS "infoadditional_additional_data", "infoAdditional"."info_additional_id" AS "infoadditional_info_additional_id" 
FROM "info_main" 
LEFT OUTER JOIN "info_additional" "infoAdditional" 
ON "infoAdditional"."info_main_id" = "info_main"."info_main_id" 
WHERE "info_main"."info_main_id" = :id

À l'heure actuelle, la jointure externe gauche nous convient, mais que faire sinon. Comment obtenir une jointure intérieure?

La fonctionnalité de création de jointures se trouve dans le package org.springframework.data.jdbc.core.convert , classe SqlGenerator , méthode:

private SelectBuilder.SelectWhere selectBuilder(Collection<SqlIdentifier> keyColumns)

Nous sommes intéressés par ce fragment:

		
for (Join join : joinTables) {
  baseSelect = baseSelect.leftOuterJoin(join.joinTable).on(join.joinColumn).equals(join.parentId);
}

Si vous avez besoin de joindre des tables, il existe une option uniquement avec une jointure externe gauche.

Il semble que la jointure interne ne puisse pas encore être réalisée.

Conclusion

Nous avons couvert deux cas les plus typiques de la façon dont vous pouvez joindre des tables dans Spring Data Jdbc.

En principe, la fonctionnalité qui est maintenant disponible est tout à fait appropriée pour résoudre des problèmes pratiques, bien qu'il y ait des limitations non critiques.



Le texte intégral de l'exemple peut être trouvé ici .



Et voici une version vidéo de ce post.