안녕하세요, 이전 주제인 이전 주제에서 이 문제에 대해 질문을 했으나, 제가 처음에 해결됨으로 표시한 후로 질문이 무시된 것 같아서, 실제로는 해결되지 않았기 때문에 새로운 주제를 개설합니다.
상황은 다음과 같습니다: 저는 Discourse로 이전했으며, 기존 포럼의 모든 멤버가 TL1 등급을 가지고 있습니다. 멤버들은 이것이 공정하지 않다고 느끼고 있으므로, 요구 조건을 변경하여 모두를 TL2로 승급시키고 싶었습니다. 이전 작업을 위해 계정을 비활성화해야 했기 때문에 상당수의 멤버가 비활성 상태입니다.
TL2 요구 조건을 게시 횟수 기준으로만 변경하고, 방문 일수는 0으로 설정했습니다.
10일 후에도 소수의 사용자만 승급되었으므로, TL2 확인이 이루어지려면 로그인하거나 답글을 게시해야 하는 것 같습니다. (아직 정확히 어느 조건인지 파악하지 못했습니다)
저는 기존 포럼의 모든 멤버에게 TL2 상태를 부여하고 싶습니다. 새로운 TL2 기준을 충족하는 사용자를 찾아서 승급하는 명령어를 어딘가에서 실행할 수 있는 방법이 있을까요?
네, @Queth. users 테이블 구조의 사본을 게시해 드릴까요? 그러면 거기에 있는 모든 항목을 확인하실 수 있습니다.
업데이트: @Queth, 여기 있습니다. 테이블 설명을 보시면 선택할 수 있는 옵션이 많다는 것을 아실 수 있습니다
users table
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를 실행하여 UPDATE를 수행하기 전에 쿼리가 원하는 결과를 반환하는지 확인하는 것이 좋습니다 :). 그리고 대량 DB 변경 작업을 시작하기 전에는 항상 전체 백업을 만들어 두세요. 실수(Fat finger mistakes)는 최고의 전문가에게도 일어날 수 있습니다. 전문가와 초보자의 주요 차이점 중 하나는 전문가가 항상 먼저 백업을 만든다는 점입니다
저도 도와드리고 싶습니다. 하지만 일부 작업은 여러분이 스스로 조금 더 조사하는 것이 더 쉽고(또는 더 좋습니다). 퍼즐 조각은 이미 모두 가지고 있으므로, 제 조언은 시간을 좀 내서 SQL 쿼리를 작성하는 법을 배우라는 것입니다. 솔직히 말하자면, 이는 온라인의 수많은 튜토리얼에서 쉽게 찾을 수 있는 PostgreSQL SQL 입문 수준의 내용입니다.
이런 “튜토리얼 101” 같은 내용을 반복해서 알려드리는 것은 제 역할이 아닙니다. 다른 사람들도 스스로 구글 검색을 통해 쉽게 찾을 수 있는 정보이니까요. 그냥 제 성격이 그렇습니다. 이해해 주셔서 감사드리며, 제 솔직한 의견에 대해 양해 부탁드립니다.
참고: SQL은 1974년, 즉 46년 전부터 존재해 왔습니다. DB 기반 애플리케이션을 관리한다면 기본적인 SQL 지식을 갖추는 것이 좋은 일입니다.
