Comments 87
Отсоединяет БД от SQL сервера; Копирует файлы БД (рядом с оригиналом) ФАЙЛБД -> ФАЙЛБД_ВЕРСИЯ; [...] Присоединяет оригинал под старым именем;
Простите, сколько у вас даунтайм при базе размером гигов в триста-четыреста?
Миграция сняла головную боль с удалением всех данных. Но ручное описание механизма обновления БД — мне надоело после 2 миграции. Автоматическая миграция — то что нужно. Минус один, при сильном изменении структуры (тип поля, поле из 1 таблицы в другую) — теряются данные.
А что мешает сначала сделать scaffold миграции, чтобы записалось изменение структуры, а потом дописать к нему перенос данных?
Основная задача велосипеда — облегчить разработку, не публикацию.
Для разработки достаточно DropCreateAlways.
Миграции — это решение для переноса в продуктив в первую очередь.
Миграции — это решение для переноса в продуктив в первую очередь.
А разработчику не нужно?
Не нужно что?
Миграция. Обновление структуры с сохранением данных.
А зачем, если вкратце?
Зачем разработчику сохранять (заведомо тестовые) данные?
Зачем разработчику сохранять (заведомо тестовые) данные?
Возможно у них нет заранее подготовленных тестовых наборов данных, так что вроде данные и не нужны, но и терять их не хочется.
Ну вообще-то это классический такой bad practice. Тестовые данные — они на то и тестовые, чтобы быть заранее хорошо известными.
Классический с чьей точки зрения?
«классиков». Как я уже писал, я опираюсь на Continuous Delivery в первую очередь, но в принципе, в отношении well-defined test data это действительно универсальный подход, вплоть до Software Requirements Вигерса.
К счастью, я не использую опыт классиков, которые не рекомендуют использовать накопленные данные.
Классики рекомендуют использовать накопленные данные по определенным правилам, а не просто так.
Теперь данные делятся на правильные и неправильные?
Так тестовые как-раз, могут быть оторванными от действительности.
Так тестовые как-раз, могут быть оторванными от действительности.
Теперь данные делятся на правильные и неправильные?
Ну вообще да, что вас удивляет?
Так тестовые как-раз, могут быть оторванными от действительности.
Это вопрос квалификации человека, который их готовил.
Если данные накоплены, и их нельзя терять — они правильные.
Данные не зависят от квалификации, они или есть или нет.
Агрегация зависит.
Данные не зависят от квалификации, они или есть или нет.
Агрегация зависит.
Почему их нельзя терять? В вашем конкретном случае, почему данные, которые использует разработчик на своей машине, нельзя терять?
Это нонсенс. Тестовые данные готовит человек. Соответственно, они зависят от его квалификации.
Данные не зависят от квалификации, они или есть или нет
Это нонсенс. Тестовые данные готовит человек. Соответственно, они зависят от его квалификации.
Потому что это данные которые будут нужны и далее.
Какие тестовые? Накопленные данные о моей работе за период.
Какие тестовые? Накопленные данные о моей работе за период.
Потому что это данные которые будут нужны и далее.
Спасибо, кэп. Но зачем?
Какие тестовые? Накопленные данные о моей работе за период.
Вы явно не следите за дискуссией. Вы пишете, что «тестовые данные могут быть оторванными от действительности». Я говорю, что это зависит от квалификации человека, который их готовил. А дальше вы почему-то пишете, что это не тестовые данные, а накопленные данные о вашей работе за период.
Вам не кажется, что где-то произошла подмена?
Почему не нужны?
Фраза была к тому что тестовые данные это необходимость, если нет реальных.
Поэтому тестовые данные — далее обсуждать не буду, изначально пост исходит, что данные терять нельзя.
Фраза была к тому что тестовые данные это необходимость, если нет реальных.
Поэтому тестовые данные — далее обсуждать не буду, изначально пост исходит, что данные терять нельзя.
Почему не нужны?
Я не говорю, что они не нужны, я спрашиваю, зачем они кокретному разработчику в конкретном сценарии.
Фраза была к тому что тестовые данные это необходимость, если нет реальных.
Отдел тестирования смеется. Тестовые данные — это необходимость сама по себе, они нужны всегда.
изначально пост исходит, что данные терять нельзя.
Данные нельзя терять почему-то. Это «почему-то» в 99% предполагает еще и SLA. Ваш подход (а) нарушает SLA (б) приводит к потере тех данных, которые могли бы быть записаны в БД в то время, пока она отключена (собственно, это и есть часть SLA)
Задача ПО — сохранение и анализ полученных данных, но разработчику они не нужны? Я не коня в вакууме пишу. Я собираю данные, расширяю поле сбора, и соответственно анализа.
Рад за Ваш, отдел. К теме какое отношение?
Нельзя терять потому что это данные, не тестовые данные, а реальные данные.
Рад за Ваш, отдел. К теме какое отношение?
Нельзя терять потому что это данные, не тестовые данные, а реальные данные.
Задача ПО — сохранение и анализ полученных данных, но разработчику они не нужны?
Разработчику они не нужны. Разработчику нужны конкретные данные, подходящие под условия задачи, на которых он эту задачу будет решать.
Нельзя терять потому что это данные, не тестовые данные, а реальные данные.
Что реальные данные делают в разработческом контуре? Им там не место.
Я так понимаю, отсюда и появляется ПО, которое написано для разработчика?
В данном случае, в БД реальные данные, которые незачем менять виртуальными, и незачем удалять.
В данном случае, в БД реальные данные, которые незачем менять виртуальными, и незачем удалять.
Я так понимаю, отсюда и появляется ПО, которое написано для разработчика?
Не понимаю вопроса.
В данном случае, в БД реальные данные, которые незачем менять виртуальными, и незачем удалять.
Мне кажется, вам уже несколько раз по треду объяснили, чем «реальные» данные хуже «виртуальных», и почему их нельзя использовать в разработческих целях.
К тому что кто-то пишет по виртуальным данным, а кто-то по реальным.
Наверное, главное, что вам удобно так вести разработку. Мне так.
Наверное, главное, что вам удобно так вести разработку. Мне так.
Да простой пример.
Мне нужен учет времени для отчета заказчикам.
Мое ПО собирает эти данные, постоянно.
Структура данных расширяется, терять старые нельзя.
Мне нужен учет времени для отчета заказчикам.
Мое ПО собирает эти данные, постоянно.
Структура данных расширяется, терять старые нельзя.
Не понимаю. Учет какого времени? Как какой-то отчет, который вы отдаете заказчикам, не является продуктом, но при этом генерится программой?
Не понимаю вашего процесса вообще.
Не понимаю вашего процесса вообще.
1. Учет моего времени
2. Учет моей программой
3. Программа в разработке
4. Пользуюсь ей я
5. Изменений в структуре — много
6. Терять старые данные — нельзя
7. Операции по миграции при каждом изменении не подходит.
2. Учет моей программой
3. Программа в разработке
4. Пользуюсь ей я
5. Изменений в структуре — много
6. Терять старые данные — нельзя
7. Операции по миграции при каждом изменении не подходит.
Так, давайте уже разбираться.
Что делает сама программа? Какова ее бизнес-задача? Какие данные хранятся в БД?
Что делает сама программа? Какова ее бизнес-задача? Какие данные хранятся в БД?
Не совсем понятно как это относится к посту.
Вы считаете, что не бывает БД, которые часто расширяются, нужно обеспечить сохранность данных, и это должно быть просто?
По задаче
1 уровень — первичка: Сбор времени, какой процесс когда и сколько запущен
2ур. обобщение процессов в программы
3ур. обобщение программ в группы программ
4ур. обобщение групп программ в категории
5ур. привязка категорий программ к пользователям
… и такая агрегация — может быть бесконечная
любой уровень может расширить или усложнить структуру
например было строковое поле Workstation стало class Workstation
1 этапом добавилось новое поле Workstation
новые данные накапливаются по двум схемам
2 этапом данные перенесутся со строки в класс
3 этапом визуализация перейдет на новую схему
между 1 и 2,3 может пройти много времени
Вы считаете, что не бывает БД, которые часто расширяются, нужно обеспечить сохранность данных, и это должно быть просто?
По задаче
1 уровень — первичка: Сбор времени, какой процесс когда и сколько запущен
2ур. обобщение процессов в программы
3ур. обобщение программ в группы программ
4ур. обобщение групп программ в категории
5ур. привязка категорий программ к пользователям
… и такая агрегация — может быть бесконечная
любой уровень может расширить или усложнить структуру
например было строковое поле Workstation стало class Workstation
1 этапом добавилось новое поле Workstation
новые данные накапливаются по двум схемам
2 этапом данные перенесутся со строки в класс
3 этапом визуализация перейдет на новую схему
между 1 и 2,3 может пройти много времени
Вы считаете, что не бывает БД, которые часто расширяются, нужно обеспечить сохранность данных, и это должно быть просто?
Я считаю, что задача «обеспечить сохранность данных при расширении БД» должна применяться только к продуктивным ландшафтам.
С точки зpения банальной эpудиции, каждый индивидуум, кpитически мотивиpующий абстpакцию, не может игноpиpовать кpитеpии утопического субьективизма, концептуально интеpпpетиpуя общепpинятые дефанизиpующие поляpизатоpы. Поэтому консенсус, достигнутый диалектической матеpиальной классификацией всеобщих мотиваций в паpадогматических связях пpедикатов, pешает пpоблему усовеpшенствования фоpмиpующих геотpансплантационных квазипузлистатов всех кинетически коpеллиpующих аспектов.
По-моему, я отвечал, просто и практично.
По-моему, я отвечал, просто и практично.
По-моему, я отвечал, просто и практично.
Что — просто?
Понимаете, ваши проблемы — это признак неправильного процесса разработки. Ну не должно, не должно в разработческом и тестовом (кроме pre-production) ландшафтах быть накопления данных, которые надо мигрировать, там должно быть «хорошо известное состояние» (well-known state).
Соответственно, если у вас в каком-то ландшафте идет накопление данных, то это повод задуматься, а что это за ландшафт? Может быть, это тестовая эксплуатация? Тогда к ней и относиться надо, как к продуктиву, включая миграции и SLA.
Это аксиома?
Это Best Practice, выработанная на тяжелом опыте. Для того, чтобы ее отвергать, нужно иметь достаточно веские основания.
Чьи Best Practice? Что для Вас веские основания? Я не отвергаю, я утверждаю что Ваш подход к разработке ПО — не единственный.
Чьи Best Practice?
Ну, лично я почерпнул эти правила из Continuous Delivery Хамбра и Фарли, и пока что ни разу в своей практике не видел ситуации, когда они (правила) бы не оправдали себя.
Но вообще правила «начинайте тестирование в предопределенных условиях» — они, как бы, самоочевидны (как бы я ни не любил это слово).
Что для Вас веские основания?
Для начала нужны хотя бы какие-нибудь основания. Выписанные в столбик с указанием минусов и плюсов по каждому решению.
Я не отвергаю, я утверждаю что Ваш подход к разработке ПО — не единственный.
Несомненно. Но надо отдавать себе отчет в том, что он не из воздуха взялся, а основан на конкретных предпосылках.
Я данные черпаю из практики.
Для меня определенные условия — реальные условия.
Я не вижу минусов в использовании накопленных данных.
Мое решение тоже не с пустого места появилось.
Для меня определенные условия — реальные условия.
Я не вижу минусов в использовании накопленных данных.
Мое решение тоже не с пустого места появилось.
Я не вижу минусов в использовании накопленных данных.
А как вы делаете тестирование, если у вас неизвестно стартовое состояние?
По-моему, если данные есть, то состояние, в какой-то мере — известно.
Угу. На уровне «данные есть». А вот какие они, каков их состав, насколько они корректны с точки зрения бизнеса — вы не знаете.
Вы знаете?
Когда использую предопределенный тестовый массив — конечно, знаю.
На основании чего, приняли решение о моих данных?
На основании того, что данные, «накапливаемые программой» по определению недетерминированы, иначе их можно было бы сгенерировать. Раз они недетерминированы, значит, мы не можем делать заключений об их корректности или некорректности.
И?
И вы, по идее, не можете написать конкретные приемочные тесты, если у вас нет точного знания «что в БД есть юзер Вася» и что «у юзера Васи строго один заказ».
… и все. На основании недетерминированных данных очень сложно строить конкретные тесты. Практически невозможно. А уж автоматизированные тесты — тем более.
Вы все к тестам и тестовым сводите.
В БД не тестовые.
В БД не тестовые.
Естественно, я все свожу к тестам, потому что какая еще активность может вестись в разработческом контуре? Прототипирование, разработка, тестирование, отладка. Это все упирается в тесты.
Есть еще и индивидуальные разработчики, у которых нет контуров.
DropCreateAlways — недостаточно. У меня ПО накапливает данные с разных источников. ПО анализирует.
Или на голых данных сидеть? Или вручную их заливать каждый раз?
Или на голых данных сидеть? Или вручную их заливать каждый раз?
А а если Seed сделать? Сгенерить набор тестовых данных и при Debug конфигурации билда раскатывать данные после миграции.
Зачем генерировать? если их можно собрать, или они уже собраны.
Можно просто в сид скрипт пихнуть. Удобно на тестовых виртуалках раскатывать. В том же тест лабе.
ПО накапливает данные с разных источников
В продуктиве, правильно?
Вот я вам про продуктив и говорю.
А чем вас бекапы не устроили? Можно даже инкерентированные делать, чтобы сэкономить место и время бекапов. Зачем эти пляски вокруг копирования?
Можно и бэкапами это сделать.
Можно и копированием таблиц внутри БД сделать.
Тут велосипед можно подправить для себя, код вроде простенький.
А копирование:
Я не хочу старое держать в рабочей БД.
Если старые данные мне не понадобились в течении Х строка — удаляю БД.
Я очень ленивый, BackUp-Restore — много действий по сравнению с F5 + Delete когда нужно.
Можно и копированием таблиц внутри БД сделать.
Тут велосипед можно подправить для себя, код вроде простенький.
А копирование:
Я не хочу старое держать в рабочей БД.
Если старые данные мне не понадобились в течении Х строка — удаляю БД.
Я очень ленивый, BackUp-Restore — много действий по сравнению с F5 + Delete когда нужно.
Все эти миграции имхо работают только на домашних проектах, в реальности это никогда не не работает. Программист должен понимать что он делает, описывать это скриптами ибо большинство изменений ниразу не тривиальны (а некоторые и неоткатываемые без бэкапов). Да и прав на базу может не быть (у нас например DBA занимаются базой, а не разработчики ПО, которое ее использует (да и база 7 ТБ — поди ее покопипасть как аффтор...) )…
А кто мешает описывать изменения через DSL? И часто базы не так сложны, что бы еще DBA держать. Есть другие способы оптимизации.
Хорошо, предложите свой вариант легкой миграции при разработке ПО когда БД не огромных размеров и есть все права.
Все эти миграции имхо работают только на домашних проектах, в реальности это никогда не не работает.
Работает. Ваши «описанные разработчиком скрипты» — это тоже миграция, просто выраженная в другой форме, вот и все.
Sign up to leave a comment.
Мой велосипед Entity FrameWork, Auto Migration, With Save Data