問題タブ [rails-models]

私はこのモデルを持っています

のrails c

ときtoken: "4e73"、しかし私がしようとすると

わかりました[]、なぜですか？

詳しくは

Rails 3.1rc4を使用して、フォーム内のネストされたモデルでいくつかの問題が発生しています。

私は現在、次のようなモデルを持っています：

と

私は明らかにこれらをわずかに切り捨てましたが、すべての重要な情報がそこにあります。

私は、新しい顧客を作成することもできる販売フォームを設定しようとしています。したがって、accepts_nested_attributes_for :customer販売モデルのラインです。

私のフォームビューは次のようになります（ここでも切り捨てられ、重要な部分のみ）：

私が抱えている問題は、フォームのレンダリング時にテキストフィールドも：first_nameのラベルも表示されないことです。エラーメッセージは表示されず、表示されないだけです。

コントローラー@sale.customer.buildの方法で試してみましたが、効果がなかったようです。new

ありがとう！

誰かが私が間違っていることを提案できますか？

編集：誤解を避けるために、私のセールスコントローラーの新しい方法は次のようになります：

コメントなしですべての投稿のスコープを作成したい...モデルで（スコープを作成することにより）、コメントだけが何を知っているように見えるので、投稿にコメントが添付されているかどうかを確認する方法がわかりませんどのコメントがそれに属しているかを知っている投稿とは対照的に、それらが属する投稿。

（間違っていたら止めてください。）

現在、ネストされたモデルを使用してフォームをセットアップしています。これまでのところ、すべて計画どおりに進んでいます。このフォームを使用して販売を作成し、そこから顧客と車両 (個別のモデル) を作成できます。

問題は、車両からネストされた別のモデルである登録番号を作成しようとしたときに発生します。基本的に、フォームにテキスト ボックスを表示することはできますが、登録番号を作成しようとするとcan not mass assign protected attribute :registration_number、コンソールでエラーが発生し、登録番号のある車両を含む販売を編集すると、テキスト ボックスが空になります。

関連するモデルは次のとおりです。

と

と

と

問題のフォームは次のとおりです。

どんな支援も大歓迎です - ありがとう!

activerecord は、新しく作成されたレコードにどのように ID を割り当てますか? ID値はいたるところにあるようです。シーケンシャルな場合もあれば、ある種のハッシュのように見える場合もあります。行動を制御する方法はありますか？

私はレールが初めてで、今学ぼうとしているので、誰かが助けてくれることを願っています.

1対多の関係を持つユーザー、意見、投票の3つのモデルがあります。それぞれuser has_many :opinionsとhas_many :votes. それぞれopinion has_many :votesとbelongs_to :user. それぞれvote belongs_to userとbelongs_to opinion. 投票テーブルには、:decision (ブール値)、:opinion_id、:user_id の列があります。意見テーブルには :content 列しかありません。

私の使用例は、ユーザーが意見を追加し、他のユーザーが各意見を表示するときに同意または反対することができるというものです (ビューを表示)。

意見表示ビューで、「同意する」と「同意しない」の2つの送信ボタンが必要です。ユーザーが投票を送信したら、この投票 (true または false) を作成し、votes テーブルの user_id フィールドと Opinion_id フィールドの両方を更新する必要があります。私は各親に対して個別にそれを行うことができましたが、同じ投票に対して両方ではありませんでした. どんな助けでも大歓迎です。

遅くなったし、これで寝たほうがいいかもしれない。簡単なもの

ユーザーが入力するフォームに 3 つのフィールドがあります。作成ボタンをクリックすると、これらのレコードがデータベースに保存されます。単純。

ただし、これら 3 つのフィールドのデータを同時に連結して、他のレコードと同時にデータベースに挿入する必要があります。これは、作成後にショーページでユーザーに反映されるはずです。

したがって、3 つの db 列を連結するアクションが必要です。列名は名、姓、生年月日です。テーブル名 PeopleDetails

モデルに組み込まれているafter_create、before_saveを使用してモデルを構築しようとしましたが、. 提案。少し寝てからまた来ようと思います

私はRailsに比較的慣れていません。

私はDeviseを通じてユーザーモデルを持っています。別の Profile モデルで、ユーザーに必要なすべての追加フィールドを持つ方が効率的かどうか疑問に思っています。

新しいモデルを作成し、そのモデルに has_one 関連付けを使用することを検討している同様の状況に遭遇していますが、 User モデル内のユーザーに属するすべての属性があれば、よりクリーンになるようです。そのような状況にどのように対処しますか？アプリケーションのパフォーマンスにどのような影響がありますか?

特にパフォーマンスの観点から、 has_one 関係を作成することの利点と欠点について詳しく説明できますか?

例として StackOverflow を使用します。Question私がモデルを持っているとしましょう。Questionログインしたユーザーは、お気に入りの 1 つとして「スター」を付けることができます。データベースでは、この種のものはおそらくフィールドとフィールドを持つUserQuestionsテーブルに格納されます。実際には「リスト」、「追加」、「削除」しかないため、この種の機能は典型的な CRUD ではありません。また、「ユーザーのスター付き質問」リストに表示されるレコードは、レコードではなく、レコードである必要があります。コントローラーとモデルに入れるコードは何ですか?user_idquestion_idUserQuestionQuestionUserQuestion

私は現在、次の 4 つの部分に分かれた Rails 3 プロジェクトに取り組んでいます。

• 公開ウェブサイト
• 管理ウェブサイト/バックエンド
• モデル
• サードパーティ データ アクセス用の API

モデルは 3 つの主要コンポーネント間で共有されるため、それらを 1 つのメイン プロジェクトに含めないようにしたいと考えています。ただし、各パーツはモデルにアクセスする必要がありますが、コードを繰り返したり、どこでも異なるバージョンを使用したりしたくありません。

現在、モデル コードは gem にあり、各プロジェクトの Gemfile では、次の行でそれらを参照しています。

ただし、同僚がシステムを評価するためにテストサーバーにデプロイするときは、外部リポジトリからモデルをプルする必要があるため、上記の行を次の行に置き換えます。

これ自体はうまく機能しますが、「バージョン」に関してはかなり不格好です (つまり、テスト サーバーに変更をデプロイするたびにバージョンを上げる必要があります)。ローカルではなく git を使用するように行を切り替えます。ファイルを適切にプッシュしていることを確認してください。

以前は、共有の git サブモジュールを使用していましたが、これも同様に厄介でした。

私はすべてを 1 つの巨大プロジェクトに組み込むことは避けたいと考えています。なぜなら、これらは巨大で保守が困難になる傾向があるからです。また、可能であれば懸念事項を分離したいと考えています。他のコンポーネントに影響を与える可能性があります - 明らかにモデルが問題を引き起こす可能性がありますが、それは私が検討し理解しているリスクです.

このようなことになると、そこにいる人々は何を提案しますか? それとも、私はそれを完全に間違った方法で行っていますか?

いくつかの追加の背景:

このアプリは、「すべてを 1 つのプロジェクトにまとめる」というモデルに従った既存の Web サイトを書き直したものです。残念ながら、ここには 2 つの問題があります。

1. アプリの開発が不十分でした - 私はこのプロジェクトを継承しましたが、最初にそれを手にしたとき、読み込み時間は 1 人のユーザーでページあたり約 2 分でした - これはその後短縮されましたが、まだ問題があります
2. 現在、現在のサイトのキャパシティ制限に達しており、今後 6 か月でさらに多くの負荷をかける必要があると予想しています。ただし、「オールインワン」アプリでスケールアウトすると、スケールアウトにリソースが浪費されることになります。それを必要としないサイトのバックエンド。

基本的に、私が分離したいものは 2 つあります。フロント エンド (公開 Web サイトと API) とバック エンドです。ソフトウェア開発について私が知っていることは、これらすべてを組み合わせることは理想的なソリューションではないことを示しています (そして過去の歴史が示しています)。これら2つを分割することは、フロントエンドのパフォーマンスを確保するという点で良い動きだと思います)。

おそらく、これを別の角度から見る必要があります。モデルを各プロジェクトに保持し、プロジェクト間でモデルを共有する代わりに、機能領域ごとに機能のサブセットを削減します (つまり、バックエンドは誰が投稿を作成したかを知る必要がありますが、フロントエンドはそれをあまり気にしないので、モデルを読み込むときはそのロジックを省略してください)。