Spring data что это
Представляем Spring Data JDBC
В предстоящий релиз Spring Data под кодовым именем Lovelace мы собираемся включить новый модуль: Spring Data JDBC.
Идея Spring Data JDBC заключается в том, чтобы предоставить доступ к реляционным базам данных без использования всей сложности JPA.
JPA предлагает такие функции, как ленивая загрузка (lazy loading), кеширование и отслеживание изменений (dirty tracking). Не смотря на то, что эти фичи очень крутые, если они, конечно, вам действительно нужны, они могут сильно усложнить понимание логики доступа к данным.
Мехнизм ленивой загрузки может внезапно выполнить ресурсоемкие запросы, или и вовсе упасть с исключением. Кэширование может встать на вашем пути когда вы решите сравнить две версии entity, а вкупе с отслеживанием изменений помешает понять — в какой же момент реально выполнятся все операции с базой данных?
Spring Data JDBC фокусируется на гораздо более простой модели. Не будет кеширования, отслеживания изменений, или ленивой загрузки. Вместо этого, SQL запросы будут выполнены тогда и только тогда, когда вы вызваете метод репозитория. Возвращаемый результат будет полностью загружен в память после выполнения метода. Не будет и механизма «сесии» или прокси-объектов для entities. И все это должно сделать Spring Data JDBC более простым и понятным инструментов для доступа к данным.
Разумеется, такой упрощенный подход выливается в целый ряд ограничений, о которых мы поговорим в следующих постах. Грядущий релиз это самая первая версия библиотеки, у нас есть много планов и замыслов, которые мы хотим реализовать, но мы вынуждены их отложить, чтобы дать вам возможность начать пользоваться Spring Data JDBC как можно раньше.
Пример
Для начала, нам нужно определить entity:
Наконец, нужно сконфигурировать ApplicationContext чтобы реализация этого интерфейса была созданы автоматически:
Давайте разберем конфигурацию более детально.
Это все, что нужно, чтобы начать работать со Spring Data JDBC. Теперь напишем тест, чтобы посмотреть, как это все работает:
Аннотация @Query
Только со стандартными методами CRUD репозитория из класса CrudRepository далеко не уедешь. Мы намеренно решили отложить автоматическую генерацию запроса — популярную фичу Spring Data, когда SQL запрос генерится на основе имени метода — на будущие релизы. А на текущий момент, вы можете просто использовать уже знакомую аннотацию @Query чтобы точно указать, какой SQL запрос должен быть выполнен.
Давайте напишем тест, чтобы посмотреть, как работает наш новый метод.
В завершение
Конечно, о Spring Data JDBC можно рассказать гораздо больше, и мы обязательно расскажем в следующих статьях.
А пока, вы можете изучить код примеров, документацию, и, разумеется, исходный код. Если у вас появятся вопросы — не стесняйтесь их задавать на StackOverflow. А если вы нашли баг или хотите запросить новую фичу — пожалуйста, создайте тикет.
Введение в Spring Data JDBC
Для будущих студентов курса «Java Developer. Professional» подготовили перевод полезного материала.
Spring Data JDBC был анонсирован в 2018 году. Целью было предоставить разработчикам более простую альтернативу JPA, продолжая при этом следовать принципам Spring Data. Подробнее узнать о мотивах, лежащих в основе проекта, вы можете в документации.
В этой статье я покажу несколько примеров использования Spring Data JDBC. Здесь не будет подробного руководства, но, надеюсь, приведенной информации хватит, чтобы попробовать его самостоятельно. Очень хорошо, если вы уже знакомы со Spring Data JPA. Исходный код вы можете найти в github.
Для быстрого старта я использовал этот шаблон.
Предварительная подготовка
Из зависимостей нам нужны data-jdbc — стартер, flyway для управления схемой и драйвер postgres для подключения к базе данных.
Далее настраиваем приложение для подключения к базе данных:
Маппинг сущностей
Для этого примера будем использовать следующую таблицу:
И соответствующий java-класс (обратите внимание, что @Id импортируется из org.springframework.data.annotation.Id ):
То увидим ошибку — ERROR: null value in column «id» violates not-null constraint. Это происходит, потому что мы не определили ни способ генерации id ни значение по умолчанию. Поведение Spring Data JDBC в части идентификаторов немного отличается от Spring Data JPA. В нашем примере нужно определить ApplicationListener для BeforeSaveEvent :
Теперь тест пройдет, потому что поле Id заполняется. Полный список поддерживаемых событий жизненного цикла смотрите в документации.
Методы запросов
Одной из особенностей проектов Spring Data является возможность определять методы запросов в репозиториях. Spring Data JDBC использует здесь несколько иной подход. Для демонстрации определим метод запроса в BookRepository :
И если запустим соответствующий тест:
Тест пройден! Не забывайте об этом при создании репозиториев.
Примечание переводчика: в Spring Data JDBC 2.0 появилась поддержка генерации запросов по именам методов.
Связи
Для работы со связями Spring Data JDBC также использует другой подход. Основное отличие в том, что отсутствует ленивая загрузка. Поэтому если вам не нужна связь в сущности, то просто не добавляйте ее туда. Такой подход основан на одной из концепций предметно-ориентированного проектирования (Domain Driven Design), согласно которой сущности, которые мы загружаем, являются корнями агрегатов, поэтому проектировать надо так, чтобы корни агрегатов тянули за собой загрузку других классов.
Один-к-одному
Класс UserAccount выглядит примерно так:
Один-ко-многим
Вот sql, который будем использовать для демонстрации связи «один-ко-многим»:
В этом примере на складе (warehouse) есть много товаров/объектов (inventoryitems). Поэтому в классе Warehouse мы также будем использовать @MappedCollection для InventoryItem :
Многие-к-одному и многие-ко-многим
В рамках этого руководства я не буду вдаваться в подробности о связях «многие-к-одному» или «многие ко многим». Я советую избегать связей «многие-ко-многим» и использовать их только в крайнем случае. Хотя иногда они могут быть неизбежны. Оба этих типа связей реализуются в Spring Data JDBC через ссылки на Id связанных сущностей. Поэтому имейте ввиду, что здесь вам предстоит еще немного потрудиться.
Заключение
Если вы использовали Spring Data JPA, то большая часть из того, что я рассказал, должна быть вам знакома. Я уже упоминал ранее, что Spring Data JDBC стремится быть проще, и поэтому отсутствует ленивая загрузка. Помимо этого, отсутствует кеширование, отслеживание «грязных» объектов (dirty tracking) и сессии (session). Если в Spring Data JDBC вы загружаете объект, то он загружается полностью (включая связи) и сохраняется тогда, когда вы сохраняете его в репозиторий. Примеры, которые я показал, очень похожи на свои аналоги в JPA, но помните, что многие концепции Spring Data JPA отсутствуют в Spring Data JDBC.
В целом мне нравится Spring Data JDBC. Признаю, что это может быть не лучший выбор для всех приложений, однако я бы рекомендовал его попробовать. Как человек, который в прошлом боролся с ленивой загрузкой и dirty tracking, я ценю его простоту. Я думаю, что это хороший выбор для простых предметных областей, которые не требуют большого количества нестандартных запросов.
На этом пока все, спасибо за чтение! Надеюсь, вы нашли это руководство полезным и оно будет отправной точкой для использования Spring Data JDBC.
Spring Framework и работа с базами данных: Spring Data JPA
В предыдущих постах о работе с базами данных в Spring Framework я поверхностно описал использование JdbcTemplate и NamedParameterJdbcTemplate. Пользоваться данными инструментами безусловно удобно, но у них есть определённые ограничения, среди которых:
В стеке Spring существует проект Spring Data, реализующий большую часть тривиальных задач и упрощающий работу с источниками данных. В качестве источников данных могут использоваться как стандартные реляционные базы данных, так и NoSQL-хранилища вроде MongoDB или Redis.
В мире Java EE стандартом дефакто для работы с базами данных является JPA (Java Persistence API). Spring Data JPA, будучи частью Spring Data, реализует взаимодействие с реляционными СУБД, основываясь на JPA.
Настройка проекта
Для использования Spring Data JPA потребуются следующие зависимости:
Если используется Spring Boot:
Если Spring Boot не используется:
Классы-сущности (Entities)
Классы-сущности дополняются стандартными для JPA аннотациями. В качестве примера возьмём класс Person, использованный уже ранее:
Я добавил в этот класс несколько JPA-аннотаций:
Репозитории
Главными компонентами для взаимодействий с БД в Spring Data являются репозитории. Каждый репозиторий работает со своим классом-сущностью. Самым простым способом создания репозитория является создание интерфейса с наследованием от CrudRepository, как показано в примере:
Первый тип (Person), переданный в дженерик CrudRepository — класс-сущность, с которым должен работать данный репозиторий, второй (String) — тип первичного ключа.
Никаких дополнительных аннотаций для работы данного репозитория не требуется, более того, не требуется даже реализация. При инициализации контекста приложения Spring Data найдёт данный интерфейс и самостоятельно сгенерирует компонент (bean), реализующий данный интерфейс.
Существует несколько типов репозиториев, различающихся по набору возможностей:
И две реализации, которые можно использовать для каких-нибудь нетривиальных задач, вроде написания реализации какого-нибудь метода с нестандартным поведением:
Запросы
Стандартный набор методов для работы с данными, предоставляемый Spring Data, достаточно лаконичен. Мы можем найти все записи класса Person или найти запись по первичному ключу. А что, если нам требуется найти запись Person по email? Данную задачу можно решить несколькими способами.
Аннотация @NamedQuery в классе-сущности
Стандартное для JPA решение — описать именованный запрос в классе-сущности:
Русские Блоги
Подробная информация о Spring Data JPA
Что такое jpa?
При использовании spring data jpa в нашем проекте вы обнаружите, что иногда отсутствует sql-оператор. На самом деле, нижний уровень структуры помог нам реализовать это. Нам нужно только следовать спецификации, чтобы использовать его. Ниже подробно обсуждаются различные аспекты jpa данных spring. Вид правил спецификации.
Использование jpa может решить некоторые из наших проблем при написании операторов sql, но если sql плохо написан в процессе разработки, это все равно будет головной болью. Конечно, эта статья не предназначена для рекламы Spring data jpa, еще одна структура уровня базы данных mybatis также является очень хорошей платформой, которая фокусируется на операторах sql.
Spring data jpa обычно используемая конфигурация jpa
Все коды, показанные ниже, взяты из хранилища spring-data-jpa моего личного github. Адрес склада: https://github.com/kickcodeman/spring-data-jpa. Читатели могут клонировать и запускать этот проект, чтобы проверить все следующее Очки знаний.
Ниже настройте общую конфигурацию application.properties проекта весенней загрузки для jpa следующим образом:
spring.jpa.show-sql=true
Эта конфигурация будет печатать операторы sql на консоли при выполнении операций с базой данных, что нам удобно для проверки и устранения неполадок.
spring.jpa.properties.hibernate.dialect=org.hibernate.dialect.MySQL5InnoDBDialect
Конфигурация диалекта базы данных.
Анализ общих аннотаций отображения классов в таблицы базы данных
Spring data jpa предоставляет множество аннотаций. Ниже мы резюмируем общие аннотации следующим образом:
Аннотация @Table также является аннотацией класса. Эта аннотация может быть использована для изменения имени таблицы. Эту аннотацию можно полностью игнорировать. Аннотация @Entity выполняет функцию этой аннотации.
@Id class attribute annotation, аннотация указывает, что поле атрибута является первичным ключом, а атрибут должен иметь и является незаменимым.
@GeneratedValue Эта аннотация обычно используется вместе с аннотацией первичного ключа @Id для определения формы представления первичного ключа. Эта аннотация обычно имеет несколько стратегий использования, которые резюмируются следующим образом:
@GeneratedValue (strategy = GenerationType.IDENTITY) Эта аннотация автоматически генерируется базой данных, а первичный ключ является самоприращивающимся. Он чаще всего используется в базе данных mysql и не поддерживается oracle.
@GeneratedValue (strategy = GenerationType.TABLE) использует определенную таблицу базы данных для хранения первичного ключа, который используется редко.
Аннотации, использованные выше, являются обычно используемыми аннотациями для определения класса сущности. С помощью приведенных выше аннотаций мы можем сгенерировать таблицу в базе данных через класс сущности. Класс сущности и таблица устанавливают соответствующие отношения. Определение класса сущности размещено ниже демонстрации:
@Setter, @Getter, @Accessors (chain = true) в этом классе сущности являются аннотациями ломбока. Если вы не понимаете, я предлагаю вам узнать о ломбоке.
Используя аннотации вышеуказанного класса сущности, при запуске проекта в базе данных будет создана таблица с именем stu.
Анализ наследования классов
Давайте изучим, как jpa работает с отношениями наследования, когда между классами существуют отношения наследования? Это достойно понимания, это означает, что мы можем получить вдвое больший результат с половиной усилий при использовании spring data jpa.
В целом различают три случая наследования:
Множество классов и несколько таблиц: извлеките общедоступные атрибуты между несколькими классами и поместите их в их общедоступный родительский класс. Каждый класс может определять свои собственные уникальные атрибуты. Подкласс и родительский класс имеют соответствующие таблицы в базе данных. Соответствующий.
Таблица создания подклассов: извлеките общие атрибуты между несколькими классами и поместите их в их общедоступный родительский класс. Каждый класс может определять свои собственные уникальные атрибуты. Только подклассы и таблицы в базе данных устанавливают связь связи, родительский класс Атрибуты в продолжаются для каждого подкласса, а таблица, соответствующая каждому подклассу в базе данных, имеет свойства, определенные в родительском классе.
Как jpa справляется с тремя вышеуказанными ситуациями? Передайте записку:@Inheritance Эта аннотация используется только в родительском классе. Существуют три стратегии для этой аннотации, соответствующие трем вышеупомянутым ситуациям соответственно. Для этой части обратитесь к моему репозиторию github.com/kickcodeman/spring-data-jpa, чтобы проверить и понять:
@Inheritance(strategy = InheritanceType.SINGLE_TABLE) Аннотацию можно примерно понять из буквального значения, и создается только одна таблица. Теперь позвольте мне сделать вывод: сценарий использования этой аннотации заключается в том, что атрибуты нескольких классов сущностей примерно одинаковы, нет никакой разницы. Единственное различие может заключаться в имени класса. В этом случае мы можем рассмотреть возможность использования этой аннотации. Если мы используем эту аннотацию, больше У каждого класса сущностей есть общая таблица, которая создается родительским классом.Поле dtype создается по умолчанию в родительском классе, чтобы указать, к какому классу сущностей принадлежат данные. Для подробного использования, пожалуйста, обратитесь к трем классам в пакете проекта com.zempty.springbootjpa.entity.inheritance.single_table, использованию трех классов A1, B1 и Group1. Группа1 в классе является подклассом A1 и B1, а в A1 и B1 Обычно используется следующая аннотация: @DiscriminatorValue Эта аннотация имеет только одно значение, чтобы пометить значение поля dtype при вставке данных. В пакете com.zempty.springbootjpa. Inheritance. Controller есть несколько подробных тестовых примеров для SingleController. Вы можете запустить проект, протестировать несколько интерфейсов и проверить базу данных на наличие правил использования.
Есть еще одно примечание, которое необходимо упомянуть здесь в отношении наследования, а именно:@MappedSuperclass Эта аннотация также используется в родительском классе. В родительском классе не требуется использовать аннотацию @Entity. Эффект от этой аннотации аналогичен третьему описанию @Inheritance (strategy = InheritanceType.TABLE_PER_CLASS), упомянутому выше, поэтому я не буду вдаваться в подробности. Объясни подробней.
Анализ взаимосвязи между классами
В базе данных существует определенная связь между таблицами и таблицами.Как jpa устанавливает аналогичные отношения между классами сущностей и таблицами базы данных?
Jpa реализует взаимосвязь между классами через серию аннотаций. Давайте подробно проанализируем, как использовать аннотации для обозначения взаимосвязи между классами. Взаимосвязь между классами может быть примерно в следующих ситуациях:
Связь один-к-одному, jpa использует аннотацию @OneToOne.
Отношение «один ко многим», jpa использует аннотацию @OneToMany.
Связь «многие к одному», jpa использует аннотацию @ManyToOne.
Отношение многие-ко-многим, jpa использует аннотацию @ManyToMany
Как следует использовать эти аннотации при использовании jpa? Ниже приведены демонстрация и объяснение с примером. Рекомендуется клонировать удаленный склад https://github.com/kickcodeman/spring-data-jpa. Все коды обращений видны на складе.
Примеры вышеупомянутых отношений:
Есть четыре физических класса: студент, аудитория, учитель, парта.
Класс обычно может вместить много студентов, и отношения между классом и учеником можно определить как @OneToMany.
Многие студенты размещаются в классе, и отношение ученика к классу можно определить как @ManyToOne.
@OneToOne
Классы сущностей стола следующие:
Вышеупомянутые два класса сущностей показывают взаимосвязь один-к-одному. Классы сущностей связаны друг с другом. Вот вопрос, который необходимо поднять:При поддержании отношений «один-к-одному» для поддержания этой связи обычно требуется третья таблица. В классе Student определена аннотация @JoinTable. Эта аннотация используется для создания третьей таблицы. Если такой аннотации нет, то Третьей таблицы не будет, просто внешний ключ генерируется в таблице stu
desk_id используется для поддержания отношений. В классе Desk в аннотации @OneToOne есть атрибут mappedBy = «desk». Это поле указывает, что класс Desk отказывается от обслуживания первичного ключа.mappedBy Этот атрибут также будет выделен ниже.
@OneToMany
Классные занятия следующие:
При использовании @OneToMany обычно следует свойство mappedBy, поскольку на одной стороне обычно не требуется поддерживать первичный ключ, а первичный ключ находится на стороне @ManyToOne.
@ManyToOne
Ключевые новые фрагменты кода в категории «Студент» следующие:
При поддержании отношений «один ко многим» и «многие к одному» внешний ключ обычно поддерживается на стороне многих.После запуска программы мы обнаружим, что новый внешний ключ class_room_id добавляется в таблицу stu.
@ManyToMany
Класс Учителя выглядит следующим образом:
Атрибут @ManyToMany класса Teacher использует mappedBy, чтобы указать, что класс отказывается от обслуживания первичного ключа. Если такого атрибута нет, будет сгенерирована избыточная таблица teacher_students. Обычно мы добавляем атрибут mappedBy к стороне многие-ко-многим, чтобы избежать дублирования таблиц. Производство.
Ключевой код Студента Студента следующий:
При поддержании отношений «многие ко многим» обычно требуется третья таблица для поддержания связи между собой. Аннотация @JoinTable используется здесь для определения имени таблицы, полей атрибутов и т. Д. Третьей таблицы.
Резюме: Взаимосвязь между классами и классами очень важна в jpa. Обязательно выясните это. Для приведенного выше отображаемого кода обратитесь к личному хранилищу https://github.com/kickcodeman/spring-data-jpa, которое можно клонировать для подробного анализа. Вот как использовать четыре отношения, описанные выше.
Дальнейший анализ работы каскада (каскад)
Что такое каскадная работа jpa?
Каскад здесь может быть трудным для понимания. Его можно понять как ассоциацию. Когда я добавляю, удаляю, изменяю и проверяю класс Student, класс ассоциации класса Student будет соответствующим образом затронут.
Как использовать каскад?
При объяснении взаимосвязи между четырьмя вышеуказанными категориями четыре аннотации взаимосвязей @OneToMany, @ManyToOne, @OneToOne, @ManyToMany имеют атрибут, называемый каскадом. Значение атрибута представляет собой массив CascadeType. Давайте сосредоточимся на объяснении и анализе. Для различных типов CascadeTypes каскад не используется, по умолчанию используется значение по умолчанию, что означает отсутствие каскада.
CascadeType.ALL имеет пять перечисленных выше каскадных функций.
Ниже мы используем примеры, чтобы проиллюстрировать использование вышеупомянутых распространенных каскадов (сохранение, обновление, удаление):Все коды случаев, показанные ниже, доступны по адресу https://github.com/kickcodeman/spring-data-jpa. Если вы используете идею для запуска проекта, в папке ресурсов есть файл тестового интерфейса test.http, который показывает случай. Все интерфейсы могут запускать тесты。
При сохранении учеников используйте каскад для сохранения парты
Код клавиши настройки каскада ученика следующий:
Код теста следующий:
Из приведенного выше кода мы видим, что при сохранении ученика стол также сохраняется в базе данных, что является волшебным эффектом каскадного сохранения.
Обновление учеников, каскадное обновление данных в классе
Ключевой код класса Студент следующий:
Код теста следующий:
Этот случай показывает, что ClassRoom был обновлен, кстати, при разговоре с новым учеником.
Удалить ученика, удалить учителя
Ключевой код студента следующий:
Код теста следующий:
Запустите тест, и вы обнаружите, что учитель также удаляется при удалении ученика. Это очень легко вызвать проблемы. Могут возникнуть следующие две проблемы:
Если у учителя есть другие родственные ученики, здесь будет сообщено об ошибке, обратите внимание.
Если учитель также настроен на каскадное удаление, при удалении учителя связанные с ним ученики также будут удалены.
Если вы не знаете, как работает каскадное удаление, это может привести к очень серьезным последствиям.Рекомендуется, чтобы читатели неоднократно проверяли этот случай, чтобы понять, как использовать каскадное удаление.
В классе есть ученики, как удалить класс
Если существует связь между классом и учеником в базе данных, возникнут проблемы, если класс будет удален, и его нельзя будет удалить обычным образом из-за внешнего ключа. Как решить эту проблему?
При удалении данных, если данные имеют внешний ключ, их нельзя удалить напрямую, Это проблема, с которой легко столкнуться при повседневном использовании, теперь дайте несколько решений этой проблемы:
Основной код ClassRoom выглядит следующим образом:
Позвольте мне рассказать о другом решении, которое не рекомендуется:
Класс Класс добавляет атрибут orphanRemoval = true в @OneToMany
Ключевые коды класса учителя следующие:
Измените удаленный тестовый код ниже, закомментируйте часть кода ученика и удалите класс напрямую, как показано ниже:
Этот эффект удаления может удалить класс, но когда вы запросите базу данных, вы обнаружите, что ученики в классе ушли, а ученики удаляются вместе с ним. Вы должны быть осторожны при использовании этого.
orphanRemoval правила использования
Атрибут orphanRemoval существует только в двух типах аннотаций отношений @OneToOne и @OneToMany.
Почему jpa помещает эту аннотацию только в эти две реляционные аннотации?
Персональный анализ заключается в использовании классов сущностей @OneToOne и @OneToMany, которые имеют внешние ключи.Операционные классы с внешними ключами, особенно при удалении, будут головной болью, поэтому такой атрибут предоставляется для устранения внешних ключей. Неприятности.
При использовании этого атрибута, то есть когда для атрибута установлено значение true, вы должны быть осторожны. Как видно из приведенного выше примера, когда я удаляю класс, студенты в классе также удаляются, и этот атрибут будет иметь Каскадный эффект.
Дальнейший анализ mappedBy
Среди атрибутов отношений в jpa очень важным атрибутом является mappedBy. Как пользователь, мы должны четко понимать правила использования mappedBy. Ниже приводится краткое изложение на основе личного опыта:
Если класс сущности использует атрибут mappedBy, можно избежать создания избыточной таблицы.Если этот атрибут не используется, после запуска программы в базе данных будет создана дополнительная реляционная таблица.
Когда класс сущности использует атрибут mappedBy, это означает, что класс отказывается от обслуживания первичного ключа, а таблица, сгенерированная этим классом, не хранит связанный с ним внешний ключ.
сопоставленПо детальному анализу
Сторона, которая использует mappedBy, отказывается от обслуживания первичного ключа. Есть некоторые детали, которые вы должны знать при каскадных операциях на стороне, которая использует mappedBy:
Обычно mappedBy использует атрибут orphanRemoval при каскадном удалении. Конечно, в аннотации @ManyToMany нет атрибута orphanRemoval. Вам все равно нужно использовать свой собственный атрибут каскадного удаления.
При каскадном сохранении и каскадном обновлении необходимо знать, что внешний ключ не связан с сохранением и обновлением связанных данных. Для поддержки внешнего ключа необходимо использовать класс ассоциации. См. Код ниже:
Каскады классов в классе для спасения учеников, и ключевые коды класса в классе следующие:
Вышеупомянутый метод обработки может сохранить студентов в базе данных при сохранении класса, ноПоскольку класс класса не поддерживает внешний ключ, хотя класс ученика успешно сохранен, он терпит неудачу, потому что связь между ними не установлена. Проверяя новые данные в таблице учеников, мы обнаруживаем, что у нового ученика нет класса Внешний ключ существует。
Как мы эффективно каскадируем сохранение?
Мы должны выяснить, кто поддерживает отношения между собой. Вышеупомянутый класс использует свойство mappedBy, чтобы отказаться от обслуживания первичного ключа. Следовательно, нам нужно использовать класс ученика для поддержания взаимосвязи друг с другом. Нам нужно установить класс в классе ученика в тестовом коде. Зайдите и проблема решена:
Улучшите тестовый код:
Разработчикам легко проигнорировать описанный выше случай, и я надеюсь, что этот случай может вам помочь.
Используйте ключевые слова spring data jpa для добавления, удаления, изменения и проверки
При использовании jpa данных Spring для добавления, удаления, изменения и проверки базы данных, в основном нам не нужно писать операторы sql, но мы должны соблюдать его правила. Давайте поговорим об этом ниже:
Как определить слой DAO
Для уровня данных spring data jpa нам нужно только определить интерфейс для наследования от JpaRepository.
Интерфейс JpaRepository определяет множество методов запросов, которые мы можем использовать, которых достаточно для добавления, удаления, изменения и проверки. Код ссылки выглядит следующим образом:
Определите уровень Дао Студента, чтобы наши добавления, удаления и изменения уже были доступны
В проекте весенней загрузки нам не нужно писать аннотации @Repository на уровне dao. Мы просто вводим их напрямую, когда мы их используем. Здесь нам нужно объяснить, что при обновлении данных мы можем сначала запросить, затем изменить атрибуты и использовать метод сохранения. Просто сохраните это.
Используйте ключевые слова для настройки запросов
Мы можем использовать ключевые слова find и get, предоставленные jpa, для выполнения обычных операций запроса, использовать ключевое слово delete для завершения удаления и использовать ключевое слово count для завершения статистики и т. Д.
Давайте посмотрим на следующий фрагмент кода, чтобы показать:
найти тестовый пример:
Получите тест по ключевым словам:
// Запрос по имени и возрасту
подсчитать статистику ключевых слов:
// Подсчитываем количество студентов с указанными именами
Вы можете увидеть вышеупомянутое использование ключевого слова find плюс By и поля для запроса, так что создается запрос запроса, который можно назвать довольно удобным. Ниже прилагается диаграмма запроса по ключевым словам, чтобы облегчить нам использование запроса по ключевым словам:
По сути, когда мы манипулируем данными, мы можем решить эту проблему, обратившись к ключевым словам в приведенной выше таблице.
jpa использует sql для добавления, удаления, изменения и проверки
Иногда мы не привыкли использовать указанные выше ключевые слова для управления данными. Нам просто нравится писать sql. Данные Spring. Jpa также поддерживает запись операторов sql. Как это использовать? Код дела следующий:
Обращаясь к приведенному выше случаю, мы можем обнаружить, чтоSQL имеет две формы представления：
Форма JPQL оператора sql, за которой следует from, представлена с именем класса.
Собственный оператор sql, вам нужно использовать nativeQuery = true, чтобы указать собственный sql
Есть также две формы передачи параметров в sql：
Используйте вопросительный знак? За ним следует числовая последовательность, числовая последовательность начинается с 1, например? 1, чтобы получить значение первого параметра метода.
Используйте двоеточие:, за которым следует имя параметра, имя параметра определяется аннотацией @Param.
Используйте сортировку для сортировки данных
Spring data jpa предоставляет класс Sort для сортировки и сортировки. Следующий код иллюстрирует использование Sort:
Приведенный выше код обычно записывает оператор sql, но добавляет только дополнительный параметр Sort. Как создать экземпляр Sort, должно быть в центре нашего внимания. Теперь посмотрите на тестовый код следующим образом:
Сортировка используется для сортировки полей.Вы можете сортировать по одному полю или вы можете установить правила сортировки для нескольких полей, но, на мой взгляд, для сортировки поля лучше использовать сортировку.
Создание экземпляра класса Sort может быть создано с помощью статического метода сортировки, который здесь не указан, просто обратитесь к приведенным выше случаям.
Операция пейджинга jpa
Пейджинг необходим, когда данных много. Spring data jpa обеспечивает хорошую поддержку пейджинга. Вот демонстрация, показывающая, как использовать пейджинг:
В соответствии с обычными шагами запроса, просто добавьте еще один параметр Pageable, как получить Pageable?
PageRequest имеет три статических метода, которые могут быть созданы:
public static PageRequest of(int page, int size)
public static PageRequest of (int page, int size, Sort sort) При разбивке по страницам вы также можете сортировать результаты после разбиения на страницы.
public static PageRequest of (int page, int size, Direction direction, String… properties) Сортировка непосредственно по полю.
jpa Use Specification
Различные методы использования jpa, представленные выше, довольно богаты, и вы можете выбирать в соответствии с вашими собственными потребностями. Ниже мы собираемся проанализировать другой метод данных запроса jpa данных spring, используя спецификацию для обработки данных:
Интерфейс наследует JpaSpecificationExecutor
Помимо наследования JpaRepository, TeacherRepository также наследует интерфейс JpaSpecificationExecutor. Давайте подробно проанализируем этот интерфейс. JpaSpecificationExecutor предоставляет нам следующие методы для использования:
Этот интерфейс имеет в общей сложности пять методов, а также предоставляет функции сортировки и разбиения по страницам. Анализируя параметры метода, мы обнаружим, что параметр Specification в методе является пороговым значением, которое мы используем. Давайте подробно проанализируем, как создать экземпляр Specification.
Спецификация анализа
Для реализации этого метода не нужно выяснять правила использования четырех классов Predicate, Root, CriteriaQuery и CriteriaBuilder:
Теперь есть такой sql-оператор:select * from teacher where age > 20
Предикат используется для установления условия поиска после where, что эквивалентно age> 20 из приведенного выше оператора SQL.
Root используется для поиска определенных полей запроса, таких как root.get («age»), поиска поля возраста,
CriteriaBuilder используется для создания диапазона полей, эквивалентного>, =,
CriteriaQuery можно использовать для создания всего оператора sql, вы можете указать поле запроса после выбора в операторе sql или объединить сложные операторы, такие как where, groupby и has.
Приведенный выше анализ является очень абстрактным. Что касается подробного использования этих четырех категорий, вы также можете обратиться к нескольким тематическим исследованиям в Интернете.
Здесь я демонстрирую очень простую демонстрацию запросов, надеясь помочь вам открыть дверь для использования спецификации.
Используйте Spring data jpa Projection (отображение проекции)
Это очень интересная часть, простая и удобная в использовании, какую проблему решает Projection?
Когда мы используем Spring data jpa для запроса данных, иногда нам не нужно возвращать данные всех полей, нам нужны только данные отдельных полей, поэтому использование Projection также является хорошим выбором.Давайте поговорим о правилах использования.
Определите интерфейс
Текущее требование состоит в том, что мне нужны только данные об имени и возрасте в таблице учителя, соответствующей классу учителя, и никакие другие данные. Определите интерфейс следующим образом:
Методы в интерфейсе начинаются с get + имя атрибута, первая буква имени атрибута пишется с заглавной буквы, например, getName (), вы также можете использовать имя целевого атрибута в аннотации @Value для получения атрибута, или вы можете объединить несколько значений атрибута в строку.
Использовать индивидуальный интерфейс
После определения интерфейса укажите данные возвращаемого типа интерфейса в методе запроса. Код ссылки выглядит следующим образом:
Запустите тест и проверьте результаты, мы обнаружим, что получаем только значения полей имени и возраста.
Продолжайте учиться и ищите волну внимания
Эта статья очень длинная и писалась уже давно. Мнения, высказанные в статье, неоднократно проверялись и пытались обеспечить точность. Если есть ошибки в выражении в статье, исправьте меня. Код случая в этой статье взят из моего репозитория github https: // github. com / kickcodeman / spring-data-jpa, вы можете клонировать и запустить тест.
Путь долог, и мне еще предстоит многому научиться. Я с нетерпением жду возможности дружить с вами, вместе обсуждать и добиваться прогресса вместе.
От себя рекомендую читать читать