не зная ситуации сказать сложно, но если есть возможность реализовать миграцию данных без простоя приложения то это и нужно сделать и мигрировать временными тасками

ну кто то может себе позволить простой в три часа ночью около 2:00, 3:00 и т.д

но может стать неприятным сюрпризом если на реальных данных миграция пойдет ОЧЕНЬ долго

например уже утро, а база еще не мигрировала.

это я понимаю, я про другое. Для работы приложения тебе непременно нужна полная миграция данных, без этого никак, правильно?

ну у меня это обычно в форме рефакторинга протекает

т.е какой то кусок данных нормализуется например.

ну так а накатывать данные кусками? Сделать очередь и пусть сервис в фоне по пачками берёт и накатывает

а разница?

зачем усложнять? )

у меня и так в фоне работает дата-миграционная таска.

ну так непонятно просто какую именно проблему ты решить пытаешься и почему у тебя фоновый таск вызывает простой сервиса

у _меня_ фоновый таск не вызывает простой сервиса

у меня миграция в два шага.

у меня и так в фоне работает дата-миграционная таска.

так таск или миграция?

Вот что предлагают ребята из Evrone на тему отслеживания тасков для миграции данных. https://github.com/achempion/software_process_framework Пункт Release history

так таск или миграция?

миграция данных

миграция данных

так. Какую проблему решаем, что тебя не устраивает в этом подходе? А то я похоже нить разговора потерял

Простой при миграции крупных данных.

например у тебя мильон записей (к примеру) и миграция данных будет идти сутки.

у _меня_ фоновый таск не вызывает простой сервиса

ты меня путаешь что-то

Неужели действительно нужно такую простую концепцию расписывать?

пусть идёт, можешь даже параллельно ещё мильён запустить, пусть тоже идёт

что ты там паралельно хочешь запустить? ты все равно в базу упираешься

у тебя сервис сутки будет простаивать?

у _меня_ фоновый таск не вызывает простой сервиса

так будет простаивать?

бля

с моим подходом не простаивает ...

Неужели действительно нужно такую простую концепцию расписывать?

не такая простая все же :) тут можно и книжку написать

зачем ты тогда пишешь про простой сервиса если ты не решаешь проблему простоя сервиса?

по двухшаговым миграциям? )

зачем ты тогда пишешь про простой сервиса если ты не решаешь проблему простоя сервиса?

ААААА

потому что если ты мигрируешь данные в рельсовых миграциях то у тебя сервис простаивает в это время

сформулируй задачу чётко и однозначно, иначе это бесполезно

сформулируй задачу чётко и однозначно, иначе это бесполезно

Миграция данных без простоя сервиса.

по двухшаговым миграциям? )

ну да, там же много всяких нюансов, я про практическую сторону. У тебя разный базы, разные приложения, разный деплой, тут реально хватит

ну да, там же много всяких нюансов, я про практическую сторону. У тебя разный базы, разные приложения, разный деплой, тут реально хватит

Пожалуй. Но ведь это обычный творческий процесс конкретных кейсов, принцип то простой.

вот в пг все хорошо, там ддл транзакционный, а вот в оракле, например, нет, и в мускуле по-моему тоже

да да да, постгрес радует что там миграции схемы можно в транзакции делать.

в мускуле нет, потому я предпочитаю с ним не связываться.

в оракле тоже нет?

странно, ожидал от энтерпрайз базы большего.

ну тут дело не в энтерпрайзе, в оракле есть более адовые фичи, но конкретно ддл не транзакционный потому что там другая схема работы со схемой

в пг в каждом процессе есть свой кэш, а в оракле он глобальный на кластер

В мускуле сейчас ддл не лочит таблицы

Поэтому простоя не будет при изменении схемы БД

транзакционность и локи таблиц это немного разное, тоже нужно иметь в виду :)

Поэтому простоя не будет при изменении схемы БД

а как работающий прод будет смотреть на внезапно изменившуюся схему?

а как работающий прод будет смотреть на внезапно изменившуюся схему?

Как написать, так и будет смотреть. При возможности код должен уметь и в старую и новую схему

Как написать, так и будет смотреть. При возможности код должен уметь и в старую и новую схему

Это и есть миграция в два шага

про которую я говорю ...

Ок, я пропустил начало обсуждения

Долго я игрался с ханами, но столкнулся с тем, что она даёт свободы больше чем рельса, требует гараздо больше опыта и вместительную голову на плечах

многие простейшие вещи усложнены. Но многие сложные вещи проще.

Забавно в общем.

многие простейшие вещи усложнены. Но многие сложные вещи проще.

как же быть?)

Смириться с конвенциями и писать на рельсах.

проще, быстрее, понятнее для команды даже сильных рубистов.

и пожалуй лучше говнокод, чем оверинженеринг, который с лёгкостью придёт в голову господам, которые с руби плохо знакомы и вообще с архитектурными паттернами.

ну, а для тех, кто все-таки хорошо знаком и с руби и с паттернами?

там с ханами всё хорошо

уже был холивар

ханами базируется на ROM, а ROM не работает

лучше взять sinatra + sequel и не ебаться

ERROR: S client not available

работает очень в лоб

лучше взять sinatra + sequel и не ебаться

а не roda?

а не roda?

ну или роду

roda + но она никогда не станет популярной такой, как синатра.

да и похуй

уже был холивар

тогда не будем начинать)

ром работает в моих кейсах.

надо писать приложения которые не зависят от фреймворков

дае в урезанном виде, в ханами.

ну типа для большенства апп не нужно что-то более, чем has_many

и это там работает.

когда я юзал ROM, то там не было поддержки PG types

ханами базируется на ROM, а ROM не работает

Слушай, у меня работает, не нужно вот этой фигни лечить тут

У него несколько поменьше цикл, чем у активрекорда

Но зато в поддержке это гораздо лучше

У него несколько поменьше цикл, чем у активрекорда

что за цикл?

Ну сколько лет тому и другому

мы уже обсуждали, что если макак-программистов научить пользоваться сервисами, и не пихать кучу логики в модель (где ее не должно быть в принципе), то с этим можно жить

будто бы ром предоставляет другую архитектурную модель.

Ну вроде того

будто бы ром предоставляет другую архитектурную модель.

будто - слитно

Да, точно.

Я же проводил аналогию с экто, по сути очень похоже

Я же проводил аналогию с экто, по сути очень похоже

где-то в чате или есть статья?

На докладе, видосик есть где-то

где-то в чате или есть статья?

https://www.youtube.com/playlist?list=PLkC6D3H7QvstNLS1ZWHCIkMmLbePMaycH во

https://www.youtube.com/playlist?list=PLkC6D3H7QvstNLS1ZWHCIkMmLbePMaycH во

большое спасибо

а вот например дока на работу с jsonb в постгресе https://github.com/rom-rb/rom-sql/blob/15019a40e2cf2a224476184c4cddab4062a2cc01/lib/rom/sql/extensions/postgres/types.rb#L170-L353 это к вопросу о типах. Можно сделать и свой тип, по аналогии

кто нибудь юзает rom.rb на практике?

здесь и кроме меня?)

ну вообще?