Приятно слушать, полезная информация. Пока шёл доклад - неспешно смотрел/находил релевантную информацию в поисковике. Например понравилось - генерация кастомной ошибки в хранимой процедуре (проверка sms-code и т.п.)
идея с обертыванием транзакции в отдельный класс и ролбеком в деструкторе, как мне кажется, порочна сама по себе. как минимум, неочевидностью происходящего. и тут же, в примере с ансетом в обработке эксепшена, вы сами это подтверждаете. ансет не вызовет деструктор. деструктор будет вызван гарбеж коллектором при освобождении ресурсов, что можно инициировать и раньше, но, обычно, это происходит при завершении скрипта. в результате, ваша транзакция остается открытой.
@@IskhartakhВы оправдываетесь. Вы даете конкретные рекомендации и приводите код. Это уже нельзя воспринимать обобщенно. И это требует конкретных уточнений. RAII общий паттерн, но это узкий паттерн. Применим он к ресурсам или общим объектам, освобождение, которых должно быть просто гарантировано, а не гарантировано в конкретный момент. транзакция таким обьектом не является. Да и при чем тут с++, если пример даете на php? Вы заведомо вводите в заблуждение, применяя RAII там, где применять его нельзя. Это справедливо в любых языках, где организована сборка мусора. и не только. в том же с++ нужно очень осторожно применять такой подход в отношении транзакций, поскольку следует понимать момент вызова деструктора или звать его явно. Но, судя по наличию в примере оператора unset, склоняюсь к тому, что Вы просто предполагали вызов интерпретатором деструктора именно в этом месте. Итог - рекомендовать RAII в отношении транзакций не только нельзя, но и противопоказано. И это нужно понимать.
@@Iskhartakh То есть, Вы не понимаете, что пример с ансетом приведет к непредсказуемому поведению, ожидая там ролбэк транзакции, который будет вызван только в завершении скрипта? а что будет с остальными обращениями к базе в таком случае, которые последуют за ансетом? Вы не можете гарантировать ролбэк транзакции в конкретном месте, применяя RAII. Это Вам тоже не понятно?
@@IskhartakhСкоупом Вы будете оперировать в с++. Вы не автор - ок. Зачем вообще писать разного рода глупости об общих принцыпах, если Вы не понимаете о чем идет речь в конкретном случае.
Спасибо!
Доклад интересный 👍
Внимание обратить стоит
Вот чего не стоит делать - так это считать, что блокировки в Redis такие же надёжные, как в базах.
Спасибо
Приятно слушать, полезная информация. Пока шёл доклад - неспешно смотрел/находил релевантную информацию в поисковике.
Например понравилось - генерация кастомной ошибки в хранимой процедуре (проверка sms-code и т.п.)
идея с обертыванием транзакции в отдельный класс и ролбеком в деструкторе, как мне кажется, порочна сама по себе. как минимум, неочевидностью происходящего. и тут же, в примере с ансетом в обработке эксепшена, вы сами это подтверждаете. ансет не вызовет деструктор. деструктор будет вызван гарбеж коллектором при освобождении ресурсов, что можно инициировать и раньше, но, обычно, это происходит при завершении скрипта. в результате, ваша транзакция остается открытой.
@@IskhartakhВы оправдываетесь. Вы даете конкретные рекомендации и приводите код. Это уже нельзя воспринимать обобщенно. И это требует конкретных уточнений. RAII общий паттерн, но это узкий паттерн. Применим он к ресурсам или общим объектам, освобождение, которых должно быть просто гарантировано, а не гарантировано в конкретный момент. транзакция таким обьектом не является. Да и при чем тут с++, если пример даете на php? Вы заведомо вводите в заблуждение, применяя RAII там, где применять его нельзя. Это справедливо в любых языках, где организована сборка мусора. и не только. в том же с++ нужно очень осторожно применять такой подход в отношении транзакций, поскольку следует понимать момент вызова деструктора или звать его явно. Но, судя по наличию в примере оператора unset, склоняюсь к тому, что Вы просто предполагали вызов интерпретатором деструктора именно в этом месте. Итог - рекомендовать RAII в отношении транзакций не только нельзя, но и противопоказано. И это нужно понимать.
@@Iskhartakh То есть, Вы не понимаете, что пример с ансетом приведет к непредсказуемому поведению, ожидая там ролбэк транзакции, который будет вызван только в завершении скрипта? а что будет с остальными обращениями к базе в таком случае, которые последуют за ансетом? Вы не можете гарантировать ролбэк транзакции в конкретном месте, применяя RAII. Это Вам тоже не понятно?
@@IskhartakhСкоупом Вы будете оперировать в с++. Вы не автор - ок. Зачем вообще писать разного рода глупости об общих принцыпах, если Вы не понимаете о чем идет речь в конкретном случае.