4.1 Транзакции и целостта на базата данни
Нормалният режим на работа на една база данни е, когато тя получава хиляди заявки всяка minutesа от стотици различни клиенти. В този случай често възникват ситуации, когато едни и същи данни са достъпни от различни заявки.
По-рядко, но отново, от време на време има ситуации, когато една заявка чете определен ред, а друга заявка го променя в същото време. Представете си Howво се случва, ако някой прочете ред, който е само наполовина променен? Нищо хубаво.
Този проблем се решава по няколко начина. Първо, можете просто да заключите реда, който се променя. И за четене и за писане. Този метод работи, но скоростта на базата страда значително.
Вторият начин е да заключите низа само за писане. Все пак ще има проблем, когато някой се опита да прочете частично променения ред. Заключение - не трябва да има ситуация, когато линията е частично променена.
Затова те измислиха трети метод - транзакциите. Транзакцията е група от действия, които се извършват or всички заедно, or нито едно. Не може да има ситуация, в която част от действията са извършени, а втората част не. Ако не е възможно да направите всички промени, всички вече напequalsи промени се връщат назад.
Всеки съвременен SQL сървър ви позволява да променяте данни само в транзакции. Отваряте транзакция, правите промени в произволен брой таблици и извършвате транзакцията. След това SQL Server се опитва да направи промени. Ако всичко е наред, те ще бъдат добавени към общата база данни. Ако е имало проблеми, всички промени ще бъдат отменени.
Hibernate също използва тази парадигма. Ето защо в предишната лекция видяхме, че при опит за запазване на обекта Employee в базата данни първо се отваря транзакция и след записването се извършва комит.
Ще разгледаме тази тема по-подробно, но засега просто знайте защо са необходими транзакции и къде обикновено се използват.
4.2 Получаване на обекти
Ако Hibernate изпълни заявка за получаване на данни, тогава няма нужда изрично да отваряте транзакция. Самата Hibernate ще направи това, ако сметне за добре: тя има своите настройки, Howто и настройките на SQL сървъра.
Ще анализираме How да работим с базата данни. И най-простият от тях е получаване на обект по неговия ID . За да направите това, използвайте метода get()на обекта на сесията . Общата форма на такова искане:
Class Name = session.get(Class.class, ID);Пример:
public User getUserById(Integer id) {
try (Session session = sessionFactory.openSession()) {
User user = session.get(User.class, id);
return user;
}
}4.3 Записване (добавяне) на обекти
Ако искате да запазите вашия обект в базата данни, тогава ще бъде изпълнена заявка на ниво SQLВМЪКНЕТЕ. Следователно вашите действия трябва да се извършват като отделна транзакция. Освен това е по-добре да използвате метода persist()на обекта на сесията за постоянство .
Общата форма на такова искане:
session.persist(An object);Методът persist()променя не само основата, но и самия обект. Работата е там, че когато добавим обект към базата данни, този обект все още няма собствен идентификатор , преди да го добавим . Е, обикновено е така, въпреки че има нюанси. И след добавянето обектът вече има ID .
public boolean saveUser(User user) {
try (Session session = sessionFactory.openSession()) {
Transaction transaction = session.beginTransaction();
session.persist(user);
transaction.commit();
return true;
}
catch() {
return false;
}
}Обектът Session също има метод save(), който изпълнява подобна функция. Просто методът save()е старият стандарт Hibernate, а методът persist()е стандартът JPA.
4.4 Изтриване на обекти
Ако искате да изтриете съществуващ обект, тогава е много лесно да го направите. За целта обектът на сесията има специален метод - remove().
Общата форма на такова искане:
session.remove(An object);И, разбира се, нека напишем codeа с пример:
public boolean removeUser(User user) {
try (Session session = sessionFactory.openSession()) {
Transaction transaction = session.beginTransaction();
session.remove(user);
transaction.commit();
return true;
}
catch() {
return false;
}
}Защо е толкова трудно, ще попитате?
Е, първо, всяHowви промени в базата данни винаги имат различни и не винаги очевидни последствия. И второ, този обект може да има дъщерни обекти, свързани с него и т.н. Така че сценариите за изтриване често са нетривиални.
GO TO FULL VERSION