МГ
и они не перетерали друг друга
Size: a a a
2021 March 09
PD
Ну, а еще генерить миграции без остановки с одновременной работой нескольких сервисов разных версий )
VR
чтобы разные разработчики могли параллельно в разных ветках добавлять свои миграции
Используйте TDB, облегчает жизнь не только в плане миграций
PD
А, а еще тестирование миграций, конечно же )
МГ
Vladimir Romanko
Используйте TDB, облегчает жизнь не только в плане миграций
подскажите, где посмотреть подробности?
МГ
от миграций одни проблемы))
VR
Миграции не могут быть сгенерированы автоматически ни в одном реально интересном кейсе, увы (
Ну можно и вручную написать, если прям что-то нетривиальное. В любом случае по объему кода это гораздо меньше, чем прикладного кода, который просто что-то фильтрует
PD
Vladimir Romanko
Ну можно и вручную написать, если прям что-то нетривиальное. В любом случае по объему кода это гораздо меньше, чем прикладного кода, который просто что-то фильтрует
Ну, вот тут вопрос, у меня на живой системе объем миграций скорее больше, чем собственно кода работы с СУБД (которого, даже без ORM, около процента от общей базы)
Там самое интересное - что кроме миграции структуры обычно нужно еще и сами данные мигрировать. Но при этом аккуратно, не одной транзакцией, с параллельной работой системы.
Там самое интересное - что кроме миграции структуры обычно нужно еще и сами данные мигрировать. Но при этом аккуратно, не одной транзакцией, с параллельной работой системы.
VR
подскажите, где посмотреть подробности?
С этим сложно. Гуглите по Trunk Based Development, Feature Togglers и Branch By Abstraction
МГ
понял, да
МГ
известная тема
S
Ну, смотри, это могут быть разные срезы на судьбу одного документа (в котором есть и текст и картинка и подтверждения и т.п.)
И в таком виде оно вполне нормально решается где угодно (хоть в РСУБД, хоть к keyvalue)
И вообще в данном кейсе основная проблема - это аккуратная криптография всего этого.
И в таком виде оно вполне нормально решается где угодно (хоть в РСУБД, хоть к keyvalue)
И вообще в данном кейсе основная проблема - это аккуратная криптография всего этого.
И что - будем хранить в дорогом storage СУБД гигабайтные сканы ? ( и в реплику их передавать) ? Или разбивать в RDBMS key-value в каких то псевдо-таблицах tClass-tAtribute - а потом их будем джойнить в 200 inner join сборках - чтобы собрать полную атрибутику экземпляра ? Нет - идея polyglot persistence - что вы один раз заносите какую то сущность, и отсальные получаются автоматически. Для этого "на борту" у вас должен стоять какой то семантический репликатор. Типа - увидел что закачали скан паспорта и тут же запустить программу распознавания и заполнения XML-data. Чтобы к моменту когда кому то потребуется иметь структурированный обьект - он уже "автоматом" появился бы в другом представлении (и быть может в другой БД)..
VR
Ну, вот тут вопрос, у меня на живой системе объем миграций скорее больше, чем собственно кода работы с СУБД (которого, даже без ORM, около процента от общей базы)
Там самое интересное - что кроме миграции структуры обычно нужно еще и сами данные мигрировать. Но при этом аккуратно, не одной транзакцией, с параллельной работой системы.
Там самое интересное - что кроме миграции структуры обычно нужно еще и сами данные мигрировать. Но при этом аккуратно, не одной транзакцией, с параллельной работой системы.
Это странно, учитывая, что миграции - это одноразовый код на выброс, его обычно не надо поддерживать. А вот прикладной код вполне надо поддерживать, рефакторить и пр., и тут статическая типизация очень даже кстати
PD
Vladimir Romanko
С этим сложно. Гуглите по Trunk Based Development, Feature Togglers и Branch By Abstraction
Увы, работает далеко не во всех кейсах и очень мало спасает от сложных миграций )
S
Ну, смотри, это могут быть разные срезы на судьбу одного документа (в котором есть и текст и картинка и подтверждения и т.п.)
И в таком виде оно вполне нормально решается где угодно (хоть в РСУБД, хоть к keyvalue)
И вообще в данном кейсе основная проблема - это аккуратная криптография всего этого.
И в таком виде оно вполне нормально решается где угодно (хоть в РСУБД, хоть к keyvalue)
И вообще в данном кейсе основная проблема - это аккуратная криптография всего этого.
Не криптография, а наверное механизмы обеспечения юридической значимости такого "преобразования". ЭЦП - лишь один из инструментов. И то не самый лучший - кто трансформировал подписанный XML в другой (уже "неподписанный") - знает какая это боль - обьяснить юристам что после такой казалось бы небольшой сортировки тегов - исходный факт не превращается "в тыкву" с точки зрения легитимности
NN
Не криптография, а наверное механизмы обеспечения юридической значимости такого "преобразования". ЭЦП - лишь один из инструментов. И то не самый лучший - кто трансформировал подписанный XML в другой (уже "неподписанный") - знает какая это боль - обьяснить юристам что после такой казалось бы небольшой сортировки тегов - исходный факт не превращается "в тыкву" с точки зрения легитимности
разве не превращается?
NN
я не холивара ради, а мнения юристов для
S
разве не превращается?
именно так. Любое изменение хотя бы в одном бите - полностью нарушает всю ЭЦП и соответсвенно легитимность. В то же время - вы можете например разрезать денежную купюру напополам или в капусту - и то будешь шанс, если сохранент номер - получить взамен новую. Или можете пролить на лист чернила - если текст и печать будут проглядывать - ваш договор не перестанет быть договором..
NN
и у вас получилось убедить в этом юристов?
AL
Пример неприятных данных - погодные api, даже профессиональные погодные сайты не для "смертных", а для авиации, например, отдают эти данные очень странно. Они не вложены как надо и не нормализованы. Даты отдельно, время отдельно, сдвиг часового пояса отдельно, нарезки температур отдельно и т.д. Вот если не обработал положить эти данные не в документную, а в key-value бд, то будет боль фильтрации. Когда нужно много срезов по разным погодным моделям.
Пример почти искусственный, его можно решить обработкой, но это пример плохих данных для РСУБД и key-value или graph.
Пример почти искусственный, его можно решить обработкой, но это пример плохих данных для РСУБД и key-value или graph.
Ой, а вы случаем с АМТК форматами не того?)