Как редактировать базу данных Discourse напрямую из GUI?

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

Существует ли что-то вроде phpMyAdmin, которое могло бы редактировать резервную копию SQL администратора Discourse? Или хотя бы работать с живым экземпляром Discourse?

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

Скачивание резервной копии (без вложений) и восстановление на локальном экземпляре PostgreSQL, который можно запросить с помощью pgAdmin3, — это ваш лучший вариант.

Да, плагин Data Explorer не позволяет вносить изменения. Однако я всё же предлагаю начать с него. Вы можете выполнить запросы, чтобы определить, есть ли у вас проблемы, а затем запустить другие запросы для выбора записей, которые нужно изменить. Это защитит вас от случайного повреждения базы данных.

Я предполагаю, что вы уже работаете в продакшене, поэтому я бы крайне осторожно относился к изменению базы данных без какого-либо одобрения со стороны команды Discourse.

Как только вы разберётесь с базой данных Discourse и поймёте масштаб проблемы, сможете рассмотреть варианты внесения изменений. Возможно, вам удастся сделать всё непосредственно в Discourse. Или же изменений окажется так мало, что будет достаточно командной строки.

Спасибо, Фалько!

Я полный новичок в работе с чем-либо, кроме мыши и кликов.

Тем не менее, мне удалось настроить локальный экземпляр Discourse (в Windows 10), следуя официальным руководствам (хотя я мало что из них понял). Предполагаю, что где-то должна быть инструкция по установке pgAdmin3 в то же место?

Глупый вопрос, но именно этот офлайн-экземпляр Discourse я должен использовать для восстановления экспортированного SQL-файла (или есть другой способ «восстановить» файл резервной копии базы данных Discourse в PostgreSQL)?

И как мне выполнить запрос после восстановления? То есть, где и как указать pgAdmin3 на базу данных в работающем экземпляре Discourse? Где физически находится база данных работающего экземпляра Discourse? Тот факт, что экземпляр Discourse запущен, блокирует базу данных каким-то образом?

Не могу найти среди файлов моего локального сервера в директории ~ /var/discourse никаких файлов, явно соответствующих базе данных.

Спасибо, Ремa.

Я самостоятельно размещаю Discourse, поэтому у меня нет доступа к команде Discourse. Я создаю и запускаю форум для небольшого сообщества исключительно на добровольной основе (то есть без бюджета) и импортирую данные из форумов MyBB и Yahoo Groups. Последние, например, привели к появлению в Discourse множества старых автоматически сгенерированных уведомлений по электронной почте в качестве тем, которые в данном контексте совершенно неактуальны.

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

Я увидел название вашего домена и впервые зашел к вам, поэтому в какой-то степени понимаю вашу ситуацию. Кстати, я нахожусь в Веллингтоне и активно создаю и использую несколько частных форумов для благотворительных организаций.

Учитывая ограниченное время и опыт, я бы рекомендовал сначала начать с самых простых и удобных инструментов, переходя к более сложным только в случае необходимости. Освоение чего-либо, выходящего за рамки первого уровня (простого использования самого Discourse), требует больших затрат. При правильном использовании Discourse может быть невероятно мощным инструментом.

  1. Графический интерфейс Discourse с функциями, которые вам в любом случае придется освоить.

    • Разберитесь с тем, что необходимо использовать в Discourse. Возможно, вы обнаружите, что 99% ваших задач можно решить, не углубляясь дальше. То есть, возможно, вам и не придется переходить на следующий уровень.

    • Приоритизируйте реальные видимые проблемы.
      Например, старые уведомления по электронной почте могут быть не такой уж большой проблемой. Если они неактуальны, то, как и задумано, они постепенно утратят свою значимость в Discourse по мере создания более актуальных тем. Главное — правильно запустить ваш форум, а не исправлять каждую ошибку в данных.
      Итак, сколько из этих автоматических уведомлений по электронной почте было преобразовано в темы?

  2. Плагин Date Explorer будет вам полезен, поэтому это следующий шаг к лучшему пониманию базы данных и выявлению того, что может потребовать доработки. В дальнейшем он поможет вам с формированием отчетов, но он не является абсолютно необходимым.

    • Невозможность внесения изменений служит страховкой: несколько лет назад многие пользователи портили свои данные поспешными обновлениями.

    • Запросы, которые вы составляете для выявления проблемных записей, всего на шаг отделяют вас от SQL-запросов для модификации базы данных.

  3. Финальный вариант, скорее всего, — использование командной строки и скриптов для модификации вашей базы данных.

    • Я бы предпочел рискнуть, показав некорректные данные, чем рискнуть повредить базу данных путем ее ручного изменения. Это может создать «бомбу замедленного действия», так как некоторые повреждения данных могут быть выявлены не вовремя.

    • Использование Data Explorer даст вам результаты запросов в виде реальных примеров данных и количественных показателей количества записей. Вы с большей вероятностью получите правильный ответ от команды и других экспертов, если они смогут понять ваши данные и то, чего вы пытаетесь достичь. Тогда они смогут посоветовать вам самый простой и безопасный способ обновления базы данных.

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

Верно. Просто не изменяйте базу данных напрямую. Однажды вы об этом пожалеете.

Спасибо, Рема.

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

В данный момент сайт на домене — это по сути чистый лист-заглушка, пока фрилансер доводит до ума процесс импорта со старых форумов (особенно настраивая скрипт импорта для MyBB, чтобы, надеюсь, к пользователям и их сообщениям импортировались и настраиваемые поля профиля, которые я там создал. Также надеюсь, что MyBB-код в некоторых постах будет разобран правильно — сейчас коды форматирования видны).

Я потратил неделю на бессмысленные попытки выполнить этот импорт самостоятельно, но так и не смог настроить среду разработки со всеми необходимыми требованиями, которая позволила бы сделать это ни на экземпляре Ubuntu под Windows 10, ни на экземпляре от DigitalOcean, следуя официальному руководству по использованию скрипта импорта MyBB.

После мучительных попыток, когда я решал одну ошибку за другой, в итоге я уперся в абсолютную стену в обоих случаях, когда дело дошло до доступности базы данных SQL при выполнении финальной команды Ruby on Rails, которая должна была запустить импорт.

И Linux, и Ruby, кажется, написаны садистами для мазохистов: оба удивительно хрупкие и архаичные. В такой среде вероятность катастрофических проблем при работе с базами данных действительно кажется высокой!

Сочувствую вам.

Оставайтесь администратором форума. :+1:

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

Но именно поэтому мне нравится Discourse. Команда прилагает усилия, чтобы сделать ядро Discourse значительно более удобным. К сожалению, миграция — это опция для продвинутых пользователей.

Почти наверняка лучше сделать это через консоль Rails.

Думаю, это зависит от ваших критериев «лучше»?
В моём случае, как у новичка, приоритетами являются минимальный порог входа и простота доступа для тех, у кого обычно не настроена среда разработки и кто ничего не знает о Ruby (и уж тем более о Linux). Всё могло бы быть иначе, если бы у меня была другая причина (и время) быстро освоить эти вещи… В идеальном мире существовало бы какое-то локальное GUI-приложение для Windows, которое могло бы напрямую взаимодействовать с моей установкой Discourse, размещённой на Digital Ocean…

Если вы решили не вносить изменения непосредственно в базу данных, вам могут оказаться полезными некоторые команды, описанные в этой теме: Administrative Bulk Operations. Например, там подробно рассказывается, как помечать темы через консоль Rails. Самое важное — сделать резервную копию базы данных вашего сайта перед выполнением любых команд.

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

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

Валидный аргумент — я постараюсь в первую очередь найти другие способы.
Моё незнание представляет большой риск в обоих сценариях, но верно ли утверждение, что выполнение любых изменений в базе данных через Ruby будет безопаснее, чем попытка внести те же изменения через pgAdmin4?

Было упомянуто, например, о риске создания незамеченных сразу повреждений — есть ли что-то в одном подходе по сравнению с другим, что может повлиять на этот риск?

На заднем плане моих мыслей: если я когда-нибудь решу рискнуть (после создания соответствующих резервных копий), я представляю себе копию pgAdmin4, запущенную на моём Digital Ocean droplet, к которой я мог бы получить прямой доступ через URL в браузере, а не через окна консольного интерфейса, тем самым устраняя несколько уровней сложности (предполагая здесь, что это вообще возможно).

В целом да. Ruby выполняет множество магических действий, чтобы гарантировать, что произойдёт именно то, что нужно. Например, если вы уничтожаете (удаляете) что-то из модели, он знает, когда и что ещё должно быть удалено. С помощью «сырого» SQL можно выполнить множество «безопасных» операций, но я почти всегда делаю это в Rails, если это возможно.

Ах, это хорошо знать — спасибо!

Выглядит потенциально довольно полезно — спасибо!

Как я решил вопрос «Как напрямую редактировать базу данных Discourse через GUI?», так как ответа, который я искал, не было.

:warning: Не делайте этого на продакшн-машине.

Здесь используется рекомендуемый административный инструмент PostgreSQL — pgAdmin 4.

Это было выполнено на моей локальной машине для изучения Discourse, например, установки, настройки, оптимизации, разработки плагинов, использования API и вебхуков и т. д.

Примечание: Discourse был установлен на Ubuntu 18.04 в среде WSL 2 под Windows 10, согласно Руководству для начинающих по установке Discourse на Windows 10 для разработки.

Примечание: WSL 2 не поставляется с systemd. Issue 457

Использовал Инструкцию по установке pgAdmin 4 на Ubuntu 20.04/18.04/16.04 как шаблон.

Используем BASH

$ echo "deb http://apt.postgresql.org/pub/repos/apt/ `lsb_release -cs`-pgdg main" |sudo tee  /etc/apt/sources.list.d/pgdg.list
deb http://apt.postgresql.org/pub/repos/apt/ bionic-pgdg main
$ sudo apt update
$ sudo apt install pgadmin4 pgadmin4-apache2

Email пользователя pgAdmin4: postgres@localhost
Пароль pgAdmin4: <пароль 1>

$ sudo /etc/init.d/apache2 restart
$ sudo ufw allow http
$ sudo ufw allow https
$ hostname -I

Запишите <адрес>

$ whoami

Запишите <имя пользователя>

Следующий шаг может быть не нужен, так как я не знал, как получить пароль пользователя базы данных Postgres, поскольку не являюсь экспертом по PostgreSQL, или был ли другой способ настроить необходимый вход в БД для pgadmin4.

$ psql postgres

Используем PSQL

postgres=# ALTER ROLE <имя пользователя> '<пароль 2>';  -- Примечание: синтаксис ALTER ROLE требует ключевого слова PASSWORD

Используем веб-браузер

http://<адрес>/pgadmin4

Пользователь: postgres@localhost
Пароль: <пароль 1>

После запуска pgAdmin4

Используем pgAdmin4

Создайте подключение к серверу

Вкладка: General (Общие)
   Name (Имя): Discourse Development
   Server group (Группа серверов): Servers
Вкладка: Connection (Подключение)
   Host (Хост): localhost
   Port (Порт): 5432
   Maintenance database (База данных обслуживания): postgres
   Username (Имя пользователя): <имя пользователя>
   Password (Пароль): <пароль 2>

Это не идеально, но работает и лучше, чем ничего. Приветствуются отзывы и предложения.


Бонус

PostgreSQL
Каталог программного обеспечения — Инструменты администрирования/разработки

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

Или, если вы хотите изменить пароль пользователя (о, это не то, что вы пытались сделать, но это всё равно хороший пример), выполните:

cd /var/discourse
./launcher enter app
rake admin:create

Несмотря на своё название, эта задача rake позволит вам:

  • создать пользователя (но это нормально, если пользователь уже существует)
  • изменить пароль (но это не обязательно)
  • сделать пользователя администратором (но это тоже не обязательно).

Посмотрите Административные массовые операции для других примеров.

Вот несколько из них:

users=User.all
me=User.find_by_username ('pfaffman')
me=User.find_by_email('jay@literatecomputing.com')
UserEmail.create!(user: me, email: 'myotheraddress@somewhereelse.com')
posts_with_uploads=Post.where("raw like '%upload%' ")
Group.create(
  name: "mygreatgroup",
  automatic_membership_email_domains: 'literatecomputing.com',
  primary_group: true,
  title: "Literate Computing Staff",
  grant_trust_level: 4,
  flair_url: 'https://example.com/path.icon.png'
)

Спасибо за обратную связь. Это ещё один урок для меня.

Хотя у меня есть многолетний опыт разработки, я никогда не использовал Ruby или Rails. На самом деле я начал программировать с перфокарт в колледже, а позже — на Atari 800.