蒼時弦也
蒼時弦也
資深軟體工程師
發表於

Apartment 與 Globalize 隱藏在方便背後的陷阱

手邊有一個專案剛好是需要滿足「多網站」並且每個網站都能夠「多語言切換」這兩個條件,在這兩個解決方案中最好處理的就是 Apartment 和 Globalize 這兩個 Ruby Gem 了。

不過,在某些情況卻變成了問題。幸好運氣不錯的是還在開發階段,還有辦法將這個問題透過替換 Gem 進行修正。

首先,我們先來大概了解 Apartment 和 Globalize 這兩個 Ruby Gem 是擔任怎樣的任務。

Apartment

Apartment 是一個 Multi-Tenancy (多租戶) 的套件,可以協助我們利用同樣的程式碼架設功能完全相同的多個網站。在一般的解決方案來說,就是自動切換連接的資料庫來達成這個效果。

另外,在 PostgreSQL 中則有 Schema 這個機制,可以讓我們在同一個資料庫做出類似 Namespace (命名空間)的效果。

透過 SET SEARCH_PATH = 'site1, public' 的設定後,當我們嘗試 SELECT * FROM users 的時候,就會先去找 site1.users 再去找 public.users (預設)的資料表,這對開發多用戶類型的系統有相當大的優勢。

不過這在大規模的網站(像是 Shopify 之類服務)在 Ruby on Rails 上就不會是個好選擇,會有效能和記憶體上的瓶頸。所以在設計上要考量應用的情境和規模。

Globalize

Globalize 可以幫助我們對 Model 設定,讓特定幾個欄位的值能夠依照當下 I18n.locale 設定的數值來自動反映出不同語言的呈現。原理上來說其實也相當簡單,他會產生一個 post_translations 資料表,並且記錄語言和需要翻譯的欄位。

使用方法如下:

1class Post < ApplicationRecord
2  translates :title, :content
3end

如此一來就能夠自動的呈現出對應的語言(如果有存到對應語言的資料)

陷阱

會發生問題其實是稍微特殊的案例,因為這個專案需要針對每次的活動產生一個新網站,但是又需要支援多語言。原本想要支援多語言,其實我們可以單純用 Apartment 去開設不同語言的網站。

但是因為這個「機制」被開設活動網站所佔用,所以我們只好借用 Globalize 的功能來完成多語言的呈現。

一般的使用上並不會有問題,不過當我們碰到「共用」的資料表(不管在哪個網站都會用這張資料表),就會發生問題。

因為是多網站,所以需要有一張表儲存目前存在的網站:

1Apartment.configure do |config|
2  config.excluded_models = %w[Site]
3end

因為每個網站的名稱都需要有中文和英文版本,所以很自然的補上了翻譯的設定:

1class Site < ApplicationRecord
2 translates :name
3end

還有將 Migration 資訊也設定後,嘗試運行 rake db:migrate 表現上是正常的。不過這是在完全沒有 Site 資料的情況下。

1  def up
2    Site.create_translation_table!(
3      {
4        name: :string,
5      },
6      migrate_data: true
7    )
8  end

當我們在做 Migrate 的時候,是不希望遺失資料。所以會將 migrate_data 選項開啟,不過這也造成了第一個我們發現第一個問題——Globalize 生成的 CREATE TABLE 是錯誤的。

解析

從 Globalize 的原始碼可以看到下面這段:

1t.references table_name.sub(/^#{table_name_prefix}/, '').singularize, :null => false, :index => false, :type => column_type(model.primary_key).to_sym

他會依據對應的 Model 來取出 table_name 這個參數,但是 table_name 因為 Apartment 要確保他是切換在正確的網站上,所以會從 sites 變成了 public.sites 來避免出問題。

基於這樣的設計,原本應該是要叫做 site_id 的欄位名稱,就變成了 public.site_id 存在於資料庫上。當 Globalize 嘗試把原本在 sites 資料表上的 name 欄位複製到翻譯的資料表上時,運行的 SQL 查詢就會恢復正常。

因為 Apartment 是對資料表層級的調整,所以在這樣的狀態下,在 Ruby on Rails 中的 ActiveRecord 預期會有的 site_id 欄位變成了 public.site_id 就會發生「找不到欄位」的錯誤。

不過這個問題並沒有想像中的困難,從原始碼可以看到清除 table_name_prefix 的機制。我們可以善加利用這個特性,在執行 Migrate 的階段暫時性的設定 table_name_prefix 在 Model 上就能正常運行。

限制

不過,當 Site 是跨網站的資料表時,我們也預期 Site::Translation 這個由 Globalize 動態生成的 Model 也應該要是跨網站的(否則 Apartment 會因為沒有指定到共用資料表,而無法取得正確的翻譯資訊。)

所以我們理所當然的增加了這樣的設定:

1Apartment.configure do |config|
2  config.excluded_models = %w[Site Site::Translation]
3end

這時候我們再次執行 rake db:migrate 卻發現出現了「資料表已存在」的錯誤。仔細一看,又是 Globalize 生成錯誤的 CREATE TABLE 查詢。

注意,這是在 Site 有存在資料的情況下,因為 Apartment 在已存在的 Schema 會採取跑 Migrate 的方式更新資料結構。

來去追查原因,原來在產生翻譯資料表 site_translations 的時候,資料表名稱是透過一個叫做 translations_table_name 的方法所定義,而這個方法則源自於 Globalize 對 Model 的擴充。

從 Globalize 原始碼可以發現:

 1      def translation_class
 2        @translation_class ||= begin
 3          if self.const_defined?(:Translation, false)
 4            klass = self.const_get(:Translation, false)
 5          else
 6            klass = self.const_set(:Translation, Class.new(Globalize::ActiveRecord::Translation))
 7          end
 8
 9          klass.belongs_to :globalized_model,
10            class_name: self.name,
11            foreign_key: translation_options[:foreign_key],
12            inverse_of: :translations,
13            touch: translation_options.fetch(:touch, false)
14          klass
15        end
16      end
17
18      def translations_table_name
19        translation_class.table_name
20      end

他會透過剛剛動態生成的 Site::Translation Model 來推斷該用什麼當做資料表的名稱。在正常的狀況下,我們會理所當然的認為是 site_translations

不過,我們使用的是 Apartment 來產生多網站的效果,也就是說名稱會變成 site1.site_translations 但是因為我們剛剛又設定了這是一張「共用資料表」所以就被改為 public.site_translations 了。

到目前為止其實都沒有問題,不過 Apartment 為了讓維護資料表是簡單的,所以實際上每一個網站的資料表會是完全一樣(直接重複所有 Migrate 動作,即使沒用到)

假設我們有 10 筆 Site 資料,那們就會變成嘗試 CREATE TABLE 10 次 public.site_translations 這個資料表,也就理所當然地會出現「資料表已存在」的錯誤。

總結

身為 Ruby on Rails 開發者,我們通常習慣於採取「已知可行」的現有解決方案,透過社群的力量共同維護一份穩定的套件來對應各種不同的情況。也因此,我們經常性地將很多細節封裝起來,造成許多人並不了解其底層的運作原理。

這也是為什麼會踩到這個陷阱的原因,因為即使是兩個知名的 Ruby Gem 兩邊的團隊也不見得會預想到「有人會想這樣使用」也不會去採取對應的措施。

可以的話,盡可能的進行事前的評估和測試(雖然本文的案例其實有點極端),就可以避免不少方法。

最後的解法是替換成使用 PostgreSQL JSON 欄位特性的 Gem 避開產生新資料表的問題,更換後的成本需要擔心的大概是 SQL 查詢受影響的程度。