أبحث عن أداة سهلة الاستخدام يمكنها تشغيل استعلامات SQL لتنظيم قاعدة بياناتي الحالية التي تحتوي على منشورات ومستخدمين تم استيرادها من منتديات أقدم - على سبيل المثال، حذف المواضيع، أو إضافة وسوم معينة لجميع المنشورات التي تحتوي على نص محدد في العنوان، أو حذف المستخدمين، أو تغيير الصلاحيات عندما لا تستوفي ملفات المستخدمين معايير معينة، وما إلى ذلك.
هل توجد أداة مشابهة لـ phpMyAdmin يمكنها تحرير نسخة احتياطية SQL لمسؤول Discourse؟ أو حتى العمل مع مثيل Discourse نشط؟
أرى أن هناك إضافة تسمح بتشغيل الاستعلامات داخل Discourse، لكن يبدو أنها لا تسمح بإجراء تعديلات على البيانات.
نعم، لا يسمح إضافة مستكشف البيانات بإجراء تغييرات. لكنني أقترح البدء بذلك على أي حال. يمكنك تشغيل استعلامات لتحديد ما إذا كانت لديك مشاكل، ثم تشغيل استعلامات لاختيار السجلات التي تحتاج إلى تعديل. وسيتم حمايتك من إتلاف قاعدة بياناتك بالخطأ.
أفترض أنك تعمل بالفعل في بيئة الإنتاج، لذا سأكون حذرًا جدًا من تعديل قاعدة البيانات دون نوع من الموافقة من فريق Discourse.
بمجرد أن تصبح على دراية بقاعدة بيانات Discourse وتعرف حجم المشكلة، يمكنك حينها النظر في خياراتك لإجراء التغييرات. قد تجد أنه يمكنك القيام بكل ذلك داخل Discourse. أو قد تكون التغييرات قليلة جدًا بحيث يكون استخدام سطر الأوامر كافيًا.
أنا مبتدئ جدًا في استخدام أي شيء لا يعتمد على النقر والإشارة بالفأرة.
ومع ذلك، تمكنت من إعداد نسخة محلية من Discourse (على نظام Windows 10) باتباع الأدلة الرسمية (دون فهم الكثير من التفاصيل)، لذا أفترض أنه يجب أن يكون هناك دليل ما لتثبيت pgAdmin3 في نفس المكان؟
سؤال تافه، لكن هل هذه النسخة المحلية من Discourse هي المكان الذي يجب أن أستعيد فيه ملف SQL المُصدّر؟ (أو هل توجد طريقة أخرى لاستعادة ملف نسخة احتياطية لقاعدة بيانات Discourse إلى PostgreSQL؟).
وكيف يمكنني استعلامها بعد الاستعادة؟ أي أين وكيف يمكنني توجيه pgAdmin3 نحو قاعدة البيانات في نسخة Discourse قيد التشغيل؟ وأين توجد قاعدة بيانات Discourse قيد التشغيل فعليًا على القرص؟ وهل حقيقة أن نسخة Discourse قيد التشغيل تقفل قاعدة البيانات بطريقة ما؟
لا أستطيع رؤية أي ملفات تبدو بوضوح وكأنها تنتمي إلى قاعدة البيانات ضمن ملفات الخادم المحلي الخاص بي في مجلد ~/var/discourse
أقوم باستضافة Discourse بنفسي، لذا لا أملك وصولًا لفريق Discourse.
أقوم بإعداد وتشغيل منتدى لمجتمع صغير، بشكل تطوعي بحت (أي بدون ميزانية)، وأقوم بنقل البيانات من منتديات MyBB ومنتديات مجموعات Yahoo. وقد أدى الأخير، على سبيل المثال، إلى إدخال عدد من إشعارات البريد الإلكتروني التلقائية القديمة ذات الطابع الإداري كمنشورات في Discourse، وهي غير ذات صلة تقريبًا في هذا السياق.
من المرجح أن أحتاج إلى اختبار وإجراء تغييرات عامة بشكل متقطع وتراكمي ومستمر، مع اكتشاف مشكلات جديدة — ومن هنا الرغبة في تقليل منحنى التعلم وتجنب أي شيء يعتمد على سطر الأوامر!
رأيت اسم نطاقك وقمت بزيارتك لأول مرة، لذا أفهم إلى حد ما وضعك. أنا في ويلينغتون، بالمناسبة، أقوم بإعداد واستخدام عدد من المنتديات الخاصة الخيرية بنشاط.
نظرًا لوقتك المحدد وخبرتك، أنصحك بالبدء بأبسط وأسهل الأدوات للاستخدام، والانتقال إلى المستوى التالي فقط إذا اضطررت لذلك. فالتكلفة عالية لإتقان أي شيء يتجاوز المستوى الأول، وهو مجرد استخدام Discourse نفسه. يمكن أن يكون قويًا بشكل لا يصدق عند استخدامه كما صُمم.
واجهة المستخدم الرسومية (GUI) لـ Discourse مع الميزات التي ستحتاج إلى إتقانها على أي حال.
احصل على معرفة كافية بما تحتاج إلى استخدامه في Discourse. قد تكتشف أنك تستطيع إنجاز 99% مما تحتاجه دون الذهاب أبعد من ذلك. لذا قد لا تحتاج إلى التقدم أكثر.
أعطِ الأولوية للمشاكل الظاهرة فعليًا.
على سبيل المثال، قد لا تكون إشعارات البريد الإلكتروني القديمة مشكلة كبيرة. فإذا كانت غير ذات صلة، فستختفي تلقائيًا من الظهور في Discourse مع إنشاء مواضيع أكثر صلة، وذلك كما صُمم النظام. لذا، فإن جعل المنتدى يعمل بشكل صحيح أهم من حل كل خطأ في البيانات.
إذًا، كم عدد إشعارات البريد الإلكتروني المؤتمتة هذه التي تم تحويلها إلى مواضيع؟
إضافة Date Explorer ستكون مفيدة لك، لذا فهي الخطوة التالية لفهم قاعدة البيانات بشكل أفضل وتحديد ما قد يحتاج إلى إجراء. لاحقًا، ستساعدك في إعداد التقارير، لكنها ليست ضرورية تمامًا.
عدم القدرة على إجراء تعديلات يعمل كشبكة أمان، لأن هناك عددًا كبيرًا من المستخدمين الذين أفسدوا بياناتهم قبل بضع سنوات بسبب التحديثات المتسرعة.
الاستعلامات التي تنشئها لتحديد سجلات المشاكل هي خطوة واحدة فقط بعيدة عن لغة SQL لتعديل قاعدة البيانات.
الخيار النهائي على الأرجح هو استخدام سطر الأوامر (command-line) والسكريبتات لتعديل قاعدة البيانات.
أفضل أن أخاطر بوجود بيانات سيئة ظاهرة على الشاشة من أن أخاطر بإتلاف قاعدة البيانات عن طريق تعديلها يدويًا. فقد يخلق ذلك قنبلة موقوتة لأن بعض تلف البيانات قد لا يُكتشف في الوقت المناسب.
استخدام Data Explorer سيعطيك نتائج استعلامات تحتوي على أمثلة حقيقية للبيانات وأرقام قابلة للقياس للسجلات. فمن المرجح أن تحصل على إجابة صحيحة من الفريق والخبراء الآخرين إذا استطاعوا فهم بياناتك وما تحاول تحقيقه. وبالتالي، يمكنهم إرشادك إلى أسهل وأأمن طريقة لتحديث قاعدة البيانات.
من المرجح أن يكون الكثير مما تحتاجه موجودًا بالفعل في مواضيع سابقة، لأن مواقع أخرى واجهت نفس النوع من المشاكل. لذا، ستكون ببساطة تنقل معرفة صعبة الكسب من شخص آخر.
كل ما ذكرته يبدو نصيحة منطقية.
ربما أتمكن من حشد مساهمة جزئية من المستخدمين إذا تمكنت من إقناع بعضهم بفحص المواضيع يدويًا ووسمها للحذف.
في الوقت الحالي، الموقع الموجود على النطاق هو مجرد صفحة احتياطية نظيفة تمامًا بينما يقوم أحد المستقلين بضبط عملية الاستيراد من المنتديات القديمة (وتعديل سكريبت الاستيراد الخاص بـ MyBB على وجه التحديد، على أمل أن يتم استيراد حقول ملف تعريف المستخدم المخصصة التي قمت بإعدادها هناك جنبًا إلى جنب مع المستخدمين ومنشوراتهم. كما آمل أن يتم تحليل كود MyBB في بعض منشورات MyBB بشكل صحيح (حاليًا، تظهر أكواد التنسيق بشكل واضح).
أهدرت أسبوعًا في محاولة فاشلة لإجراء هذا الاستيراد بنفسي، لكنني لم أستطع أبدًا إعداد بيئة تطوير تحتوي على جميع المتطلبات اللازمة للقيام بذلك، سواء من خلال نسخة من Ubuntu على نظام Windows 10 أو عبر مثيل مستضاف على DigitalOcean، وذلك بناءً على الدليل الرسمي لاستخدام سكريبت الاستيراد الخاص بـ MyBB.
بعد معاناة شديدة وتجاوز رسالة خطأ تلو الأخرى، اصطدمت في النهاية بحائط صلب في كلتا الحالتين عندما يتعلق الأمر بجعل قاعدة بيانات SQL قابلة للوصول عند تنفيذ أمر Ruby on Rails النهائي الذي سيعمل على بدء عملية الاستيراد.
يبدو أن كلًا من Linux و Ruby مكتوبان من قبل ساديين، للماسوشيين، حيث أن كلاهما هش وغامض بشكل مذهل. في مثل هذه البيئة، تبدو احتمالية حدوث مشاكل كارثية عند التلاعب بقواعد البيانات عالية جدًا!
أعتقد أن ذلك قد يعتمد على معيارك لـ ‘أفضل’؟
في حالتي، كوني مبتدئًا، فإن أقل منحنى تعلم ممكن وأبسط طريقة للوصول لشخص لا يملك عادةً بيئة تطوير مُعدّة، ولا يعرف شيئًا عن Ruby (أو حتى Linux)، ستكون من الأولويات العليا. قد يختلف الأمر لو كان لدي سبب آخر (ووقت كافٍ) للتعرف على هذه الأمور… في عالم مثالي، سيكون هناك نوع من تطبيق واجهة رسومية على ويندوز يمكنه الاستفسار مباشرةً عن إعدادات Discourse المستضافة على Digital Ocean…
إذا قررت عدم إجراء التغييرات مباشرة على قاعدة البيانات، فقد تجد بعض الأوامر الموصوفة في هذا الموضوع مفيدة: Administrative Bulk Operations. على سبيل المثال، يوفر تفاصيل حول كيفية وضع علامات على المواضيع من وحدة تحكم Rails. والأهم من ذلك هو أخذ نسخة احتياطية من قاعدة بيانات موقعك قبل تشغيل أي أوامر.
معياري لـ “الأفضل” هو “أقل احتمالية بكثير لأن تترك قاعدة بياناتك في حالة معطلة أو معطلة تمامًا.” وبما أنك “مبتدئ”، فأنت لا تعرف الجداول التي تحتاج إلى تحديث عند القيام بـ … شيء ما.
بغض النظر عن الطريقة التي تتبعها، تأكد من إجراء نسخ احتياطي متكرر.
نقطة صحيحة - سأبذل قصارى جهدي للبحث عن طرق أخرى في المقام الأول.
جهلي يشكل خطرًا كبيرًا في أي من السيناريوهين، لكن هل من الصحيح القول إن إجراء أي تغييرات على قاعدة البيانات عبر Ruby سيكون أكثر أمانًا من محاولة إجراء نفس التغييرات باستخدام pg Admin4؟
تم الإشارة إلى خطر إحداث أضرار لا تُلاحظ على الفور، على سبيل المثال - هل هناك أي شيء في أحد النهجين مقارنة بالآخر يمكن أن يؤثر على هذا الخطر؟
في خلد ذهني، إذا قررت يومًا المخاطرة بذلك (بعد أخذ نسخ احتياطية مناسبة)، فقد تخيلت نسخة من pgAdmin4 تعمل على قطرة Digital Ocean الخاصة بي، يمكنني الوصول إليها مباشرة عبر عنوان URL في المتصفح، بدلاً من ذلك عبر نوافذ وحدة التحكم في سطر الأوامر، وبالتالي التخلص من بضع طبقات من التعقيد (أفترض هنا أن هذا ممكن حتى)
إلى حد كبير. يقوم Ruby بالعديد من الأشياء السحرية لضمان حدوث الشيء الصحيح. على سبيل المثال، إذا قمت بتدمير (حذف) شيء ما من نموذج، فإنه يعرف متى وما هي الأشياء الأخرى التي يجب حذفها. هناك الكثير من الأشياء “الآمنة” التي يمكنك القيام بها باستخدام SQL الخام، لكنني أفعل ذلك دائمًا تقريبًا في Rails إذا كان ذلك ممكنًا.
$ 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
بريد مستخدم 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>';```
---
باستخدام متصفح الإنترنت
```bash
http://<العنوان>/pgadmin4
المستخدم: postgres@localhost
كلمة المرور: <كلمة المرور 1>
بمجرد بدء تشغيل pgAdmin4
باستخدام pgAdmin4
إنشاء اتصال خادم
التبويب: General
الاسم: Discourse Development
مجموعة الخوادم: Servers
التبويب: Connection
المضيف: localhost
المنفذ: 5432
قاعدة بيانات الصيانة: postgres
اسم المستخدم: <اسم المستخدم>
كلمة المرور: <كلمة المرور 2>
هذا ليس مثاليًا لكنه يعمل وهو أفضل من لا شيء. نرحب بالتعليقات والاقتراحات.
على الرغم من أن لدي عقودًا من الخبرة في التطوير، إلا أنني لم أستخدم Ruby أو Rails من قبل. في الواقع، بدأت البرمجة باستخدام بطاقات مثقوبة أثناء دراستي الجامعية، وعلى المستوى الشخصي باستخدام Atari 800.
لا تفعل ذلك على جهاز إنتاجي.