مرحبًا، أنا أفتح موضوعًا جديدًا لهذا الأمر، إذ أعتقد أن أسئلتي في موضوع سابق حول هذا الشأن قد تم تجاهلها منذ أن وضعت عليها علامة “تم الحل” في البداية، بينما لم يُحل بعد.
الحالة: لقد قمت بالانتقال إلى Discourse، ويحمل جميع أعضاء المنتدى القديم مستوى ثقة 1 (TL1)، وهو ما يعتبرونه غير عادل. لذا أردت رفع مستواهم جميعًا إلى TL2 عن طريق تغيير المتطلبات. وكثير منهم غير نشطين لأنني كان عليّ تعطيل حساباتهم قبل الانتقال.
قمت بتغيير متطلبات TL2 لتعتمد فقط على عدد المنشورات، وجعلت عدد أيام الزيارة صفرًا.
بعد مرور 10 أيام، تم ترقية عدد قليل جدًا من المستخدمين، مما يوحي بأن المستخدمين يجب أن يسجلوا الدخول أو يردوا على منشور ما لكي تتم عملية فحص TL2 (لم أكتشف بعد أي من الأمرين هو الصحيح).
أود حقًا أن أتمكن من منح جميع الأعضاء السابقين في منتداي وضع TL2، فهل هناك طريقة لتنفيذ أمر ما في مكان ما للقيام بذلك؟ شيء مثل المرور على جميع المستخدمين وترقيتهم إذا استوفوا معايير TL2 الجديدة.
لا مانع لدي من تغيير الإضافات مؤقتًا إلى tl2، وأعتقد أنني يمكنني تعيين مستوى الثقة (TL) يدويًا لاحقًا. أظن أن هذا لن يؤثر على قدرات الإضافة؟ أليس كذلك؟
شكرًا لك! نحن نتحدث عن 20 ألف مستخدم، 10 آلاف منهم لديهم مستوى ثقة 1 (tl1) بعد الهجرة، والـ 10 آلاف الأخرى لديهم مستوى 0. أريد فقط ترقية أولئك الذين لديهم مستوى 1، ويمكنني فعل ذلك باستخدام هذا الاستعلام، أليس كذلك؟
User.exec_sql("UPDATE users SET trust_level = 2 WHERE trust_level IN ( 1)")
نقطة أخرى هي أنه في غضون ذلك، تم تسجيل أعضاء جدد حقيقيين لا أريد ترقيتهم إلى مستوى 2 دون أن يستحقوا ذلك
هل توجد طريقة لإضافة معيار يتعلق بتاريخ التسجيل؟ مثلًا، جميع المستخدمين الذين لديهم مستوى ثقة 1 والذين سجلوا قبل 17 مارس 2020؟
نعم @Queth، هل تود أن أنشر لك نسخة من هيكل جدول المستخدمين حتى تتمكن من رؤية جميع الإدخالات المختلفة فيه؟
تحديث: إليك الأمر يا @Queth… يمكنك أن ترى من وصف الجدول أن لديك الكثير من الخيارات
جدول المستخدمين
discourse=# \d users
Table "public.users"
Column | Type | Collation | Nullable | Default
---------------------------+-----------------------------+-----------+----------+-----------------------------------
id | integer | | not null | nextval('users_id_seq'::regclass)
username | character varying(60) | | not null |
created_at | timestamp without time zone | | not null |
updated_at | timestamp without time zone | | not null |
name | character varying | | |
seen_notification_id | integer | | not null | 0
last_posted_at | timestamp without time zone | | |
password_hash | character varying(64) | | |
salt | character varying(32) | | |
active | boolean | | not null | false
username_lower | character varying(60) | | not null |
last_seen_at | timestamp without time zone | | |
admin | boolean | | not null | false
last_emailed_at | timestamp without time zone | | |
trust_level | integer | | not null |
approved | boolean | | not null | false
approved_by_id | integer | | |
approved_at | timestamp without time zone | | |
previous_visit_at | timestamp without time zone | | |
suspended_at | timestamp without time zone | | |
suspended_till | timestamp without time zone | | |
date_of_birth | date | | |
views | integer | | not null | 0
flag_level | integer | | not null | 0
ip_address | inet | | |
moderator | boolean | | | false
title | character varying | | |
uploaded_avatar_id | integer | | |
locale | character varying(10) | | |
primary_group_id | integer | | |
registration_ip_address | inet | | |
staged | boolean | | not null | false
first_seen_at | timestamp without time zone | | |
silenced_till | timestamp without time zone | | |
group_locked_trust_level | integer | | |
manual_locked_trust_level | integer | | |
secure_identifier | character varying | | |
Indexes:
"users_pkey" PRIMARY KEY, btree (id)
"index_users_on_secure_identifier" UNIQUE, btree (secure_identifier)
"index_users_on_username" UNIQUE, btree (username)
"index_users_on_username_lower" UNIQUE, btree (username_lower)
"idx_users_admin" btree (id) WHERE admin
"idx_users_moderator" btree (id) WHERE moderator
"index_users_on_last_posted_at" btree (last_posted_at)
"index_users_on_last_seen_at" btree (last_seen_at)
"index_users_on_uploaded_avatar_id" btree (uploaded_avatar_id)
Referenced by:
TABLE "user_security_keys" CONSTRAINT "fk_rails_90999b0454" FOREIGN KEY (user_id) REFERENCES users(id)
TABLE "poll_votes" CONSTRAINT "fk_rails_b64de9b025" FOREIGN KEY (user_id) REFERENCES users(id)
TABLE "bookmarks" CONSTRAINT "fk_rails_c1ff6fa4ac" FOREIGN KEY (user_id) REFERENCES users(id)
من الجيد دائمًا استخدام SELECT أولاً والتأكد من رضاك عن استعلامك قبل التحديث :)، ودائمًا قم بنسخة احتياطية كاملة قبل البدء في التعديلات الجماعية على قاعدة البيانات. فكلنا عرضة لأخطاء الإصبع السمين حتى أفضل الخبراء. إحدى الفروق الرئيسية بين الخبير والمبتدئ هي أن الخبير دائمًا ما يقوم بنسخة احتياطية أولاً
سأود ذلك بشدة؛ لكن بعض الأمور أسهل (وأفضل) إذا قمت أنت ببعض البحث بنفسك. لديك جميع قطع اللغز، لذا نصيحتي لك هي أن تخصص بعض الوقت لتعلم كتابة استعلام SQL. بصراحة، هذا مجرد أساسيات في PostgreSQL يمكن العثور عليها في عدد لا يحصى من الدروس عبر الإنترنت.
هذا ليس “مجال تخصصي” لإعادة تكرار أشياء من نوع “الدروس الأساسية” التي يمكن للآخرين العثور عليها بسهولة عبر بحثهم الخاص في جوجل. هذا مجرد أنا. شكراً لفهمك، وأرجو أن تعفوا عن صدقي.
ملاحظة: لغة SQL موجودة منذ عام 1974، أي منذ 46 عاماً. من الجيد أن تمتلك معرفة أساسية بـ SQL إذا كنت ستقوم بإدارة تطبيق يعتمد على قاعدة بيانات.
شكرًا لك
حسنًا، لدي معرفة أساسية جدًا، لكن كتابة الاستعلامات من الصفر لا تزال شيئًا أفضل لي أن أنسخه وألصقه من مصدر موثوق بدلاً من محاولة ابتكاره بنفسي.
من الجيد دائمًا استخدام SELECT أولاً والتأكد من رضاك عن استعلامك قبل استخدام UPDATE ، ودائمًا قم بنسخ احتياطي كامل قبل البدء في إجراء تغييرات جماعية على قاعدة البيانات.
