Hacktoberfest 2026：维护者为十月标记出来的 issue，仍然开放、适合新手。 浏览 Hacktoberfest issue

Remove unused unsubscribed column from members

已关闭
  • 哪里不对？
#3,007 0 条评论 0 个 reaction 已指派 1 人 在 GitHub 查看

维护者通常 1 天内回复

@mroderick 已经在做这个了。

开始于 2026年10月12日。

评估

这个 Issue 还没有评估数据。

描述

Problem

The members.unsubscribed boolean column is dead and should be dropped. Nothing reads or writes it. It survives in db/schema.rb and in production data only.

Git history shows when it died:

  • 2013-10-21 (86bae547): migration 20131021040356_add_unsubscribed_to_member.rb added the nullable boolean, MembersController#unsubscribe set it to true, and the invitation email carried the unsubscribe link.
  • 2014-03-29 (bd0772a2): default_scope -> { where(unsubscribed: [false, nil]) } became the only read.
  • 2014-06-22 (59df6c1c): that default scope was removed. Nothing has read the column since.
  • 2014-08-24 (0cdd988a): the unsubscribe action became a signed-token redirect to the subscriptions page. The write went with it. Nothing has written the column since.

Unsubscribing today runs through soft-deleted subscriptions (Discard, tombstones per #2920); the newsletter opt-in is tracked in opt_in_newsletter_at. The originating migration was deleted with the pre-2026 migration purge (fd7e972f).

Production data

The column still holds the 2013-2014 clicks (snapshot 2026-10-12): 84 true, 6 false, 29,576 NULL. All 90 non-null values belong to members created between 2013-10-21 and 2014-07-01. Of the 84 flagged members, 11 hold active subscriptions today and have received mail for years regardless of the flag, and 2 have opted into the newsletter since.

Recommendation: drop the column without changing any subscription state. The flag has been inert for over 12 years; acting on it now would apply decade-old intent over current state, including over the 2 later opt-ins. The counts above are the last trace of the feature.

Why the two-step removal is load-bearing

Production runs with Heroku preboot: the release phase runs migrations before new dynos boot, and old dynos keep serving against the new schema during the switch. Old releases build their member SELECT list from their schema cache and name every column explicitly (SELECT "members"."id", ..., "members"."unsubscribed", ...). Dropping the column while old dynos serve would fail every member query on them with PG::UndefinedColumn. Writes are not affected: partial_inserts keeps the nullable, default-less column out of INSERTs.

So the removal stays as proposed:

  1. Add unsubscribed to self.ignored_columns on Member and deploy. The column then drops out of the new release's SELECT list and out of the model's attribute methods.
  2. In a separate deploy, wrap remove_column :members, :unsubscribed in safety_assured. strong_migrations 2.8 prescribes exactly this sequence.
Verification notes
  • grep and ast-grep across app, lib, config, spec, db: no code reference to the column. Matches are comments, locale strings, view prose and spec variable names only.
  • No migration in db/migrate/ references it. The originating migration was deleted in fd7e972f.
  • No database views or triggers reference the column.
  • The codebar auth app does not reference the column.
  • Member.all.to_sql on master names members.unsubscribed in the SELECT list; with ignored_columns set it does not.
主要语言
Ruby
星标
105
派生
206
平均合并
19 小时 31 分钟
30 天内合并 PR
84

环境准备

  • 提供 Dockerfile 或 Docker Compose 文件
  • 没有 Pull Request 模板
  • 阅读贡献指南

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

codebar/planner 的其他 Issue

查看 codebar/planner 的全部 Issue

相似的 Issue

更多 Ruby Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。