Rails 3個的意外JSON行爲

模型Rails 3個的意外JSON行爲

class Project 
has_many :tasks 

class Task 
belongs_to :project

Task具有以下屬性（其中包括）

t.string project 
t.integer project_id

這是我繼承的代碼，我不知道爲什麼它有兩列，但我注意到這個設置出現意外的行爲。當我渲染JSON用於@task，它包括project信息本身（可能無法正確格式JSON，但你的想法）

{ 
    "task": { 
    "duration": 3, 
    "project": { 
     "project": { 
     "id": 9, 
     "description": "Roofing, 
     "updated_at": "2011-09-07T16:58:34Z", 
     ... 
     } 
    }, 
    "project_id": 9, 
    ... 
    } 
}

我檢查數據庫project列，它是零。看起來Rails像關係調用那樣處理了這個列（我可以看到爲什麼），而不僅僅是一列，那是否意味着行爲？

來源

2011-09-07 Johnny Klassy

什麼是「項目」欄（字符串類型）？我看你有外鍵'project_id'，看起來是正確的。 – dwhalen

是的，如上所述，'project'列的類型是'string'。 –

對不起，不清楚，我的意思是「什麼是項目專欄？」，它存儲了什麼數據？我在說（鍵入字符串）來區分它與integer類型的'project_id'。顯然'project'是一個字符串。 – dwhalen

我認爲你在命名衝突的假設中是正確的。實際上你可以像這樣訪問你的任務項目（task.project），所以當rails JSON渲染器呈現task.project時，它會像你猜測一樣拉下它的關係的JSON格式。我建議您將該列的名稱更改爲不與rails的慣例衝突，或者如果您不想更改數據庫列（請參閱:class_name選項），但可以更改關係的名稱，但可能會導致更多混淆馬路。我剛剛讀到你繼承了那個代碼。通常，當您指定模型關係時，您將自動獲取諸如project_id之類的屬性以及訪問任務項目的助手方法project。也許代碼的作者沒有意識到這一點，並認爲有必要自己創建這兩列。保留project_id可能沒問題，但project屬性顯然是相互衝突的。

或者，您可以自己重寫JSON格式，方法是在您的模型中使用簽名def as_json(options={})定義一個方法，該方法返回表示您希望的JSON格式的散列，例如。 { :name => task.name, :project => something_else }。

來源

2011-09-07 19:52:12

是的，我對名稱衝突是正確的，我諮詢了原始開發人員（他是Rails的新手），並確保沒有真正用於'project'的列，我刪除了它，現在它不再提取相關的'project'信息。 –

Rails 3個的意外JSON行爲

回答

相關問題