Я точно не хочу допускать ошибок, так как у меня 1,6 млн сообщений.
Есть ли способ нацелиться только на один конкретный пост, чтобы провести тесты перед заменой строк во всех постах?
Я создал «тестовый» пост на своём форуме с набором тегов BB в различных контекстах.
Сколько времени займёт замена строки в более чем 1 млн постов?
Если это займёт много времени, есть ли более быстрый способ? Может быть, редактирование текста напрямую в базе данных?
Есть ли способ выполнить несколько замен одновременно (например, добавлять новые строки до и после тегов [quote], заменять [b] и [i] на ** и *, удалять [color] и [indent] и т. д.)?
Редактирование: можно ли применить эти изменения к необработанному содержимому постов через Rails, а затем пересобрать все посты — сработает ли такой подход?
Информация к сведению: после нашей миграции 1 млн постов из vB3 в Discourse примерно полгода назад:
При миграции из vB мы провели полную очистку данных и рефакторинг тегов bbcode, используя множество кастомных скриптов на Ruby в скрипте миграции.
Мы выяснили, что для нас это оказалось наиболее эффективным: очистить всё, запустив множество регулярных выражений gsub на Ruby по постам vB перед их вставкой в базу данных Discourse.
В противном случае вам придётся выполнять множество запросов к PostgreSQL по сырым постам Discourse и заново обрабатывать (recook) посты.
После тщательного тестирования мы решили проводить всю предобработку во время миграции (а не после неё). Мы пришли к выводу, что это «быстрее» способ выполнить идеальную миграцию.
Подскажите, есть ли способ импортировать только сообщения, не затрагивая уже импортированные данные Discourse, особенно те, которые связаны с идентификаторами сообщений (пользователи, темы, вложения, постоянные ссылки и т. д.)?
Импорт занимает так много времени, что если я что-то упустил и придется импортировать всё заново, это снова займёт дни.
Когда скрипт импортировал сообщения, он создавал около 50 000 сообщений Discourse в час. Почему повторная обработка (rebake) занимает так много больше времени?
Я прекрасно понимаю твою боль. После нашей первоначальной миграции мы написали много кастомного кода на Ruby, чтобы очистить более десяти лет копипасты кода со всех уголков планеты; не говоря уже о всех проблемах с кодировкой (mojibake) и странных наборах символов; а также о различных вложенных BB-кодах, которые требовали значительной доработки на Ruby для аккуратной очистки во время миграции.
Это было нетривиальной задачей и заняло много времени (и бесчисленных попыток миграции); но мы в основном являемся форумом для программистов, поэтому, если твой форум состоит преимущественно из текста (а не кода), процесс должен быть более straightforward.
Нашей команде также пришлось написать много «довольно сложных регулярных выражений для экранирования всего и вся», так как конвертация всего этого унаследованного вложенного BB-кода в Markdown нетривиальна, учитывая, сколько вложенного BB-кода люди публиковали за годы. Мы также удалили множество BB-кодов, которые, по нашему мнению, спустя годы после публикации не представляли особой ценности.
Отвечая на твой первоначальный вопрос выше:
Да, ты можешь просто закомментировать методы, которые хочешь пропустить в скрипте миграции.
Мы фактически полностью переписали многие методы миграции, но они были отличной отправной точкой и очень полезны, учитывая, что миграция из vB3 была и остается неподдерживаемой.
Я знаю это, но если я просто запущу скрипт миграции, он пропустит существующие сообщения.
Если я удалю все импортированные сообщения Discourse перед повторным запуском миграции, я предполагаю, что при повторном импорте им будут присвоены новые ID (ID сообщений Discourse), отличные от предыдущей миграции, и все ссылки на эти сообщения, скорее всего, будут нарушены.
Если это вообще возможно, гораздо проще попросить импортера исправить эти вещи. Если вы уже запустили сайт, это будет долго и мучительно. Можно попытаться создать скрипт импорта, который изменит уже импортированные сообщения, но я не знаю никаких моделей того, как это сделать.
