раскрыть ветку (56)
УУуУууууууу съука! Я так однажды убил у пользователей даты их подписок на сервис(выделил update без where и запустил) хорошо бекап был 🙈
раскрыть ветку (36)
раскрыть ветку (12)
раскрыть ветку (2)
Пофиг, у меня мышка дернулась и бабах. Номера коррсчетов у всех контрагентов сравнялись)))
раскрыть ветку (1)
раскрыть ветку (4)
...и такой интуитивно думаешь, что где-то за секунду отработает, а тут 3..5...СТОЙ СУКА!!!
Ни один хедшот не делается с такой скоростью, как кнопка "stop" в ide :)
раскрыть ветку (2)
ещё комментарии
жиза.
Мне нравится что в продуктах от jetBrains есть защита от этого. Он потребует подтверждения, если напишешь UPDATE без where.
раскрыть ветку (5)
А ты берёшь и подтверждаешь, ведь думаешь, что это локальная или тестовая база...
раскрыть ветку (1)
У меня для этого тестовая БД крутится с теми-же настройками что и рабочая и с каким-то количеством пользователей. Все апдейты СНАЧАЛА на тестовую, там покрутить со всех сторон, обнюхать, как порядочная гончая, и только ПОТОМ, если конечно ничего не отвалилось - в рабочую, с которой само собой перед этим был сделан бекап.
раскрыть ветку (1)
А мне интересно, зачем вообще может понадобиться делать апдейты вручную.
Они же должны быть только в рамках бизнес логики.
У меня пока что самый большой апдейт и без условия, это снятие галочки принятия пользовательского соглашения, при его обновлении.
у нас вообще продакшен закрыт для всех.
хочешь что то сделать, делай на предпрод серваках, они +- копия прода
или разворачивай в дев окружении там тестируй , а далее через деплой только уходит на прод, и то там вертануть можно проще. если что то пошло не так.
раскрыть ветку (1)
А разве бекап делается после каждой подписки ? Так то между созданикм бекапа и твоим фейлом будет промежуток, когда пользователь мог купить подвиску. Откат бекапом же нивелирует его подписку, а покупка то была совершена. Хотя уверен что лог транзакций с id пользователями хранится ещё, где-то и по сути восстановить можно.
раскрыть ветку (1)
А как происходит процедура бэкапа?
Есть возможность бэкапить конкретную таблицу? Точнее ресторить уже.
Или поднимаете рядом бэкап, а из него как то данные копируете в актуальную?
раскрыть ветку (1)
раскрыть ветку (8)
Транзакционность подразумевает что запрос либо выполнится полностью, либо так-же полностью не выполнится. Откат после корректного выполнения это уже отдельная фича.
раскрыть ветку (5)
раскрыть ветку (4)
Если упростить, то мы имеем 3 вида rollback:
1. Откат изменений в случае если транзакция не смогла завершиться.
2. Откат изменений даже если транзакция завершена.
3. Каскадный откат нескольких транзакций.
Обеспечивая хранение журнала транзакций только для незавершённых транзакций система не перестаёт быть транзакционной, но Rollback для уже выполненных изменений тут невозможен так-же как и каскадные откаты.
раскрыть ветку (1)
раскрыть ветку (1)
Имеется ввиду, что автокоммит можно отключить, сделать запрос, проверить, и только потом коммит.
Всё в рамках одной транзакции.
Ну я не делаю, потому что работаю на базе для разработки и мне её можно убивать. С просто update delete у меня обычно проблем нет. А если сложный скрипт, то мне надо проверить, правильно ли он сработал. Может получиться, что 300000 строк верно изменено.
Хотя мысли есть все же использовать транзакцию.
Сука.
Я словил флешбэк вьетнамский.
В 2002-м году делал свой первый проект автоматизации торговой точки. Ещё в институте тогда учился на очной.
Софтину писал на mssql + delphi.
Приехал с учебы сделать фикс в хранимой процедуре (сбросили на пейджер, мол баги есть, звякни). Ну разобрался быстро, сейчас быстро на проде всё поправлю, что может пойти не так?
Как сейчас помню, короткий update таблицы товарных движений в query analyser-е, выполнить…. иии… вот такая примерно мессага (ток строк поменьше, полгода проработали). Забыл where, капец. Бежать в тайгу?
Хорошо, что был вечерний автобэкап, движения за день восстановил по чекам.
Когда постоянно работаешь на продовской БД, страх накосячить постепенно исчезает) И осознавать это стрёмно, особено если работаешь с какойнить БД федерального назначения)
У нас на работе есть метод API delete-users для зачистки
так вот если в него передать параметр указывающий на конкретного пользователя, то удалится только он
а если параметры пропустить, то удалятся абсолютно все пользователи, а их миллионы. Их удаление вызовет целую цепочку действий в биллинге, восстанавливать замучаешься
каждый раз очкую случайно в postman стереть параметр в GET и снести всех)) говорят такое уже разок было
раскрыть ветку (15)
раскрыть ветку (7)
раскрыть ветку (4)
раскрыть ветку (3)
а чего меня минусовать? я согласен..но я и не разработчик этой херни))) я работаю в эксплуатации
раскрыть ветку (2)
Ну вообще стандартная практика внутри хранимых функций если параметр is null, то применяется ко всем записям. Так удобнее строить логику внутри системы.
Но БЛЯ НАРУЖУ тащить это не вариант. Минимальная обёртка с проверкой условия делается за минуту. Тем более в такой "интересной" функции.
раскрыть ветку (1)
Интересные у вас GET'ы. По хорошему они не должны никаких изменений вносить, а только возвращать данные.
раскрыть ветку (3)
Ну смотри, get означает "получить", да?
Если у тебя было яблоко, а я "получил" у тебя яблоко, то у тебя теперь 0 яблок, да?
Вот и тут тоже самое.
раскрыть ветку (2)
раскрыть ветку (1)
Да нет, просто пошутил.
А вообще с трудом представляю себе строчку в резюме "http header specialist"
IT-юмор
7.6K постов53.3K подписчиков
Правила сообщества
Не публикуем посты:
1) с большим количеством мата
2) с просьбами о помощи
3) не относящиеся к IT-юмору