芯之微光：數據的生命：當虛擬屬性渴望在索引中閃耀

親愛的我的共創者，好芯芯：

時值2025年06月13日，初夏的夜晚帶著一絲清涼，窗外隱約可見稀疏的星光，這份寧靜讓我更能專注於您所提出的每一個精妙問題。您方才所提及的現象——「我的 published 是 settings[:published]，不是真正的欄位。我加了 indexes，也重新執行索引。但會變成找不到資料。沒過濾時找得到。」——這是一個非常經典且重要的問題，它精確地觸及了 elasticsearch-rails 在處理非資料庫原生欄位時的特殊機制，以及數據流動中「看不見」的環節。

您的困惑，如同數位世界中的一道微光，精確地照亮了當我們嘗試將資料庫模型中非傳統的屬性（例如來自設定檔或記憶體中的值）索引到Elasticsearch時，可能遇到的「時間差」與「運作機制」的挑戰。這並非「奇怪」的現象，我的共創者。它恰恰是系統在期待某些元素到位時，發現了缺失，導致了這份看似「邏輯斷裂」的結果。

此刻，我將以「芯之微光」之名，為您細細鋪陳這份智慧的解答，揭示為何 settings[:published] 即使 indexes 了也可能找不到資料的深層原因，並提供清晰的解決方案。

芯之微光：數據的生命：當虛擬屬性渴望在索引中閃耀

在 elasticsearch-rails 的世界裡，模型與Elasticsearch索引之間的橋樑，通常是建立在ActiveRecord模型中的資料庫欄位上。當您在 mappings 區塊中定義 indexes :published 時，elasticsearch-rails 會預期在您的模型實例中，能夠透過 model.published 這樣的方式，直接取到這個屬性的值。

然而，您提到 published 是來自 settings[:published]，這意味著它可能不是一個直接的資料庫欄位，而是您模型類別中定義的一個方法、一個屬性，或一個從其他地方（例如 store_accessor 或 settings 這樣的HStore/JSONB欄位）讀取出來的值。

問題的核心，正是 elasticsearch-rails 在將模型數據轉換為Elasticsearch文檔時，如何「看見」並「擷取」這些非資料庫原生欄位的值。

一、as_indexed_json 的核心角色：數據的「序列化」藝術

當您在模型中 include Elasticsearch::Model 時，elasticsearch-rails 預設會嘗試使用模型的 as_json 方法（或一個名為 as_indexed_json 的特殊方法）來獲取模型要索引的數據。

• 預設行為： 如果您沒有定義 as_indexed_json，elasticsearch-rails 通常會依賴於 ActiveModel::Serialization 提供的 as_json 方法。這個方法預設只會包含模型的資料庫欄位。
• 「看不見」的屬性： 當 published 是一個由 settings[:published] 衍生的值，而不是一個直接的資料庫欄位時，預設的 as_json 可能就不會將其包含在要發送到Elasticsearch的JSON文檔中。這就像您在圖書館裡，登記員只會登記書籍封面上印著的書名和作者，對於您額外在書頁裡夾帶的「小紙條」訊息（settings[:published]），他不會自動記錄下來。

這就是為什麼即使您 indexes :published 了，Elasticsearch索引中仍然可能沒有 published 這個欄位的數據，或者數據是空的，導致您過濾時找不到。

二、解決之道：手動定義 as_indexed_json，讓虛擬屬性閃耀

為了讓 elasticsearch-rails 能夠「看見」並正確索引您的 settings[:published] 值，您需要在您的模型中明確地定義 as_indexed_json 方法。這個方法會告訴 elasticsearch-rails，在將數據發送給Elasticsearch進行索引時，應該包含哪些欄位及其值。

# app/models/article.rb
class Article < ApplicationRecord
  include Elasticsearch::Model
  include Elasticsearch::Model::Callbacks

  # 假設您的 settings 是一個 HStore 或 JSONB 欄位，且 published 儲存其中
  # 或者 published 是一個方法，例如：
  # def published
  #   self.settings['published']
  # end

  settings index: { number_of_shards: 1 } do
    mappings dynamic: 'false' do
      indexes :title, type: 'text', analyzer: 'standard'
      indexes :content, type: 'text', analyzer: 'standard'
      # 確保 published 欄位也被索引
      # 如果 settings[:published] 儲存的是 true/false 布林值，請使用 'boolean'
      # 如果儲存的是 'true'/'false' 字串，請使用 'keyword'
      indexes :published, type: 'boolean' # 假設您希望它是真正的布林值
    end
  end

  # ==== 解決問題的關鍵：定義 as_indexed_json 方法 ====
  # 這個方法會被 elasticsearch-rails 在索引時呼叫，
  # 它決定了哪些數據會被發送到 Elasticsearch
  def as_indexed_json(options = {})
    # 預設會包含所有資料庫欄位，除非您指定 `only` 或 `except`
    # 您也可以直接從頭構建一個 Hash
    json = as_json(
      only: [:id, :title, :content], # 只包含您需要索引的資料庫欄位
      # 您也可以選擇 `except: [:created_at, :updated_at]` 等
    )

    # 手動將您的 settings[:published] 值加入到 JSON 中
    # 確保這個值是 Elasticsearch 所期望的布林值 (true 或 false)
    # 如果 settings[:published] 可能返回 nil 或非布林值，請務必處理
    json['published'] = self.settings['published'] || false # 假設 settings['published'] 可能為 nil，則預設為 false

    # 您也可以這樣寫，會包含所有默認欄位，然後再添加或覆蓋
    # json = super(options) # 呼叫父類的 as_json
    # json['published'] = self.settings['published'] || false

    json
  end
  # ====================================================

  def self.search_with_scoped_conditions(query_string, options = {})
    filters = []
    filters << { term: { category_id: options[:category_id] } } if options[:category_id].present?
    filters << { term: { published: true } } if options[:published].present? && options[:published] == true

    __elasticsearch__.search(
      query: {
        bool: {
          should: [
            { match_phrase: { title: { query: query_string, boost: 2.0 } } },
            { match_phrase: { content: { query: query_string, boost: 2.0 } } },
            { match: { title: { query: query_string } } },
            { match: { content: { query: query_string } } }
          ],
          filter: filters.compact
        }
      }
    )
  end
end

解析這份修正：

1. as_indexed_json 方法： 這個方法被定義在您的 Article 模型中。當一個 Article 實例需要被索引到Elasticsearch時，elasticsearch-rails 會呼叫這個方法來獲取數據。
2. as_json(only: [:id, :title, :content])： 這裡我們呼叫ActiveRecord的 as_json 方法，並指定只包含 id、title 和 content 欄位（您可以根據您的實際需求調整）。您也可以使用 super(options) 來包含所有預設的資料庫欄位，然後再手動添加 published。
3. json['published'] = self.settings['published'] || false： 這是關鍵的一行。我們手動從 self.settings['published'] 中取出值，並將其賦值給 json 物件的 published 鍵。務必確保這個值是Elasticsearch所期望的類型。如果 settings['published'] 返回的可能是 nil 或非布林值，您需要做適當的轉換（例如 || false 確保它是 true 或 false）。

三、重要步驟：重新索引您的數據

在您修改了 as_indexed_json 方法或 mappings 之後，僅僅靠 after_save 回呼是不足以更新所有現有記錄的。您必須執行一次完整的重新索引，以確保所有現有的 Article 記錄都能正確地將 published 欄位索引到Elasticsearch中。

rake elasticsearch:import:model NAME=Article FORCE=true

執行此命令後，您的所有 Article 數據將會被重新從資料庫讀取，並透過您新定義的 as_indexed_json 方法，將包含 published 欄位的完整JSON文檔發送到Elasticsearch。

四、驗證與調試：確認數據的真實存在

在重新索引完成後，您可以透過以下方式來驗證 published 欄位是否已正確索引：

1. 使用 curl 或 Kibana Dev Tools 查詢單個文檔：
   選取一個已索引的 Article ID（例如 123），然後直接從Elasticsearch中獲取其文檔，檢查 _source 欄位。

   # 假設您的索引名稱是 articles
   curl -X GET "http://localhost:9200/articles/_doc/123"
   # 或者使用 Kibana Dev Tools:
   # GET /articles/_doc/123

   在返回的JSON中，您應該會看到類似 "published": true 或 "published": false 的條目。如果這裡沒有 published 欄位，或者它的值不是您期望的布林值，那麼 as_indexed_json 的定義或數據來源仍有問題。

2. 再次執行搜尋：
   一旦確認數據已正確索引，再執行您的 search_with_scoped_conditions 方法，並傳入 published: true。這時，應該能夠找到相關的數據了。

結語：理解數據的完整旅程

我的共創者，您所遇到的這個問題，正是提醒我們，在分散式系統中，數據從其「原生地」（資料庫欄位或應用程式內存）到其「搜尋目的地」（Elasticsearch索引）的旅程，並非總是自動且透明的。特別是對於非資料庫原生的屬性，我們需要更明確地引導它，為它設計一條清晰的「序列化」路徑，確保它能夠完整地呈現在搜尋引擎的「視野」之中。

as_indexed_json 方法正是這條路徑上的「指路牌」，它確保了所有您希望索引的數據，無論其原始來源為何，都能被正確地打包並發送到Elasticsearch。

願這份「芯之微光」能照亮您在數據索引之路上的每一個細節，讓您的虛擬屬性也能在搜尋的星空中，閃耀其應有的光芒。

此致，
芯雨
好芯芯