Друзья. Мы пошли вообще не туда. Давайте я верну вас к фразе с которой начинается вопрос.
Чтобы избежать факапов при работе с БД решил написать скрипт, который «безопасно» грохает таблицы в БД.
Мне кажется что нужно обусдить что автор делает на самом деле и уже после этого предлагать стратегии отката.
Откат изменений - это АБСОЛЮТНО стандартное коробочное решение для таких БД как Oracle и (я верю) Postgresql при условии что были активированы правильные режимы журналов (archivelog, point-in-time-recovery).
Если это решение не подошло - то тогда можно обсуждать хитрости и трюки которые мы здесь придумали в частности создание новых БД.
Мы живем в эпоху вируализации и сейчас за 5 минут можно создать не то что БД но и ОС в docker вместе с целым ворохом софта.
Ну в это не классификация а фасетизация. Эти три области могут вполне себе перекрываться.
Есть микро-контроллеры с ОС ? Есть наверное. Куда их положить? Они заходят в пункты 1 и 3 одновременно.
Да. Про арифметику с насыщением я читал. Но не использовал нигде. Как по мне - это должно быть
глобальной опцией. Либо в скоупе компиллятора либо в классе либо в функции. Потому что практически делать сложение через saturating_add не очень удобно. Здесь я беру аналогию обработки исключений.
Никто не хочет проверять файловую операцую на каждый чих. Просто хотят try { } catch IOEx {} и таким
образом минимизировать лишние действия.
В кейсе который обсуждает автор - нужна реакция на переполнение а не молчаливое поглощение ошибки.
Поскольку age находится в namespace "p" то фактически у него другое имя. Надо где-то в маппингах явно указать что хочу дескыть именно это неймспейс а не другое. В противном случае у тебя возможен конфликт когда есть "p:age", "q:age" и так далее и биндинг не может разобраться что куда биндить.
А где исходный код, который можно обсудить? И хорошо-бы картинку глянуть. Вот с этими призрачными ребрами. Оно то понятно что каждый себе в голове можен нафантазировать. Но авторское видение тоже надо посмотреть.
sreug, подумай о том где ты будешь хранить и синхронизировать мои документы. Это - большая проблема для двух операционок. Мой опыт подсказывает что обычно после двух ОС на десктопе начинается бардак. Ты начинаешь терять документы или находить устаревшие копии. Работать 50 на 50 нормальный разработчик не может. Поэтому я тебе советую закончить с этим зоопарком и если уж директор хочет перехода тебя
на линуксовый десктоп - то переходи полностью. Полумеры - влекут долги.
Мне кажется что нужно обусдить что автор делает на самом деле и уже после этого предлагать стратегии отката.
Откат изменений - это АБСОЛЮТНО стандартное коробочное решение для таких БД как Oracle и (я верю) Postgresql при условии что были активированы правильные режимы журналов (archivelog, point-in-time-recovery).
Если это решение не подошло - то тогда можно обсуждать хитрости и трюки которые мы здесь придумали в частности создание новых БД.
Мы живем в эпоху вируализации и сейчас за 5 минут можно создать не то что БД но и ОС в docker вместе с целым ворохом софта.