أواجه مشكلة حقيقية مع العديد من المستخدمين لدي. يمكن رؤية المستخدمين في لوحة الإدارة على النحو التالي:
لكن عندما أحاول إظهار عنوان بريدهم الإلكتروني، لا يظهر لي أي شيء. كما أن ملفهم الشخصي العام يعطي خطأ 404.
بقدر ما أستطيع أن أرى، جميع هؤلاء المستخدمين غير نشطين تقريبًا (هم نشطين من حيث التفعيل ولكن غير نشطين من حيث النشاط في المنتدى). لذا أعتقد أن السبب قد يكون في آلية إزالة المستخدمين غير النشطين تلقائيًا التي تعطلت في الماضي البعيد.
شيء آخر ألاحظه:
إذا قمت بإلغاء تفعيلهم ثم تفعيلهم مرة أخرى، سيتم إصلاحهم!
إذا كان المستخدم غير نشط لفترة معينة (730 يومًا افتراضيًا)، فسيتم تعطيله تلقائيًا. يوجد هذا الإعداد في لوحة التحكم الخاصة بك تحت الإعدادات/المستخدمين، ثم قم بالتمرير تقريبًا إلى الأسفل. هناك ستجد هذا الخيار. لكن، لا داعي لإجراء أي تغييرات لمجرد التغيير. إذا لم يسجل هؤلاء المستخدمون دخولهم منذ عامين، فلا معنى لإعادة تفعيلهم ما لم يبدأوا في الظهور مرة أخرى. 
لا. مشكلتي ليست هذه. لوحة التحكم تُظهر أن المستخدمين مفعلون.
يبدو مشابهاً لـ المشكلة التي أعاني منها. هل يمكنك التحقق مما إذا كانت الأسماء المتأثرة تحتوي على تكرارات أو «تطابقات قريبة جداً» في قاعدة بياناتك؟ على سبيل المثال user.user و useruser.
نعم، يتأثر المستخدمون من بين أسماء المستخدمين شائعة جدًا. لذا يقترح discourse اسم مستخدم مشابهًا. أقوم بتسجيل المستخدمين عبر واجهة برمجة التطبيقات (API). لذا أحصل على اسم مستخدم من المستخدم، ثم أتحقق منه مقابل واجهة برمجة التطبيقات الخاصة بـ discourse، وإذا كان محجوزًا بالفعل، سأستخدم تلقائيًا ما يقترحه discourse.
بالمناسبة، وبمساعدة من @RGJ، تمكنا من تحديد المشكلة في هذين الشرطين:
بالإضافة إلى ذلك، فإن المشكلة التي يواجهها @hosna هي بوضوح مشكلة على مستوى قاعدة البيانات. يبدو أن هناك بعض التلف في جدول المستخدمين. نسخ المحتويات إلى جدول جديد يحل هذه المشاكل.
مع ذلك، لاحظت حالتين لمشكلة @bartv في قاعدة بيانات @hosna (كانتا النسخ المكررتين قبل 22 سبتمبر، وكلاهما يحتوي على نقطة في اسم المستخدم)، لكنني لست متأكدًا مما إذا كانت هاتان المشكلتان مرتبطتين. إنهما تتشاركان فقط في الأعراض نفسها.
يبدو أن هذا مؤشر قاعدة بيانات تالف. يجب أن يحل الأمر REINDEX TABLE users المشكلة.
ماذا عن أسماء المستخدمين المكررة؟ لدي العديد من أسماء المستخدمين نفسها تُستخدم لـ مستخدمين متميزين.
تم الاعتراف بالمشكلة هنا:
هذا على الأرجح أثر جانبي لفهرس تالف. قد تحتاج إلى تنظيفه يدويًا قبل أن تعمل عملية إعادة الفهرسة.
هل يمكنك شرح كيف قد يحدث فهرس تالف؟ وكيف يمكن منع ذلك في المستقبل؟
فشل في العتاد، أو خلل في Postgres،… يصعب الجزم. يحدث هذا.
باستثناء أن ذلك مستحيل لأن الفهرس تالف.
هذا هو الحل:
# إنشاء جدول مؤقت بدون قيود ونسخ المحتويات إليه
create table users_test (like users);
insert into users_test select * from users;
# إزالة أسماء المستخدمين المكررة بحساسة لحالة الأحرف، المكررات بعد 22 سبتمبر
delete from users_test where username in (
select username
from users_test
group by username
having count(username)>1
) and created_at>'2019-09-22' ;
# إزالة أسماء المستخدمين المكررة غير حساسة لحالة الأحرف، المكررات بعد 22 سبتمبر
delete from users_test where lower(username) in (
select lower(username)
from users_test
group by lower(username)
having count(lower(username))>1
) and created_at > '2019-09-22' ;
# مشكلتان متبقيتان، احذفهما بشكل فردي
delete from users_test where id in (184534,130826);
# إنشاء جدول جديد مع القيود ونسخ المستخدمين إليه
create table users_clean (like users including indexes);
insert into users_clean select * from users_test;
ثم أعد تسمية users إلى users_old و users_clean إلى users.
أود أن أتدخل هنا لأقول إن هذا قد يكسر قاعدة بياناتك أكثر من المستخدمين المعطّلين!
نحن الآن عالقون في منتصف طريق الترقية، حيث تعتمد العديد من القيود لا يزال على users_old منذ إعادة تسمية الجدول، ولم يظهر هذا الأمر كمشكلة إلا بعد بضعة أيام من تطبيق هذا الإصلاح غير المكتمل ظاهريًا. كما أن عبارة like users including indexes غير كافية (فهي ستتجاهل تسلسل id مثلًا).
أنت محق تماماً، أتذكر حقاً أنني اضطررت لإعادة إنشاء القيود بعد إعادة تسمية الجداول.
أعتذر عن هذا الإغفال المهم.
من ملاحظاتي:
alter table poll_votes drop constraint fk_rails_b64de9b025;
alter table poll_votes add constraint fk_rails_b64de9b025 FOREIGN KEY (user_id) REFERENCES users(id);
alter table user_security_keys drop constraint fk_rails_90999b0454;
alter table user_security_keys add constraint fk_rails_90999b0454 FOREIGN KEY (user_id) REFERENCES users(id);
وفي الوقت الحالي أيضاً:
alter table bookmarks drop constraint fk_rails_c1ff6fa4ac;
alter table bookmarks add constraint fk_rails_c1ff6fa4ac FOREIGN KEY (user_id) REFERENCES users(id);
وكإخلاء مسؤولية مهم: استخدم هذا فقط عندما تكون متأكداً تماماً مما تفعله!
يبدو أن هذا يتطابق بالفعل مع ما اكتشفناه بعد الاستعلام عن pg_catalog للقيود التي تؤثر على users_old.
كما أتذكر أن تضمين القيم الافتراضية including defaults كان مطلوبًا على الأقل لتجنب تعطيل عملية التسجيل.
شكرًا لك على التصحيح!