メソッドに適したUserモデルに変換する変換関数を自動的に生成するので、これは重要です。ビューに変換する変換関数を自動的に生成します。完全なビューオブジェクトグラフを作成するためのコードを生成することができます。これらのリンクを作成してあなたのビューに埋め込むためのコードを生成します。それらのモデルも取得して設定します。メディアタイプの例を次に示します。メディアタイプのコレクションである「reviews」という属性があることを指定します。メディアタイプの「default」ビューに含まれています。モデル間の関係を定義する必要があります。これをどのようにしているかを見ることができます。命名法を採用しています。リレーションをサポートしています。モデルとニーズとの関係を指定します。関係を宣言する必要があります。各フィールドを追加しましたが、必ずしも指定する必要はありません。自動的にそれらをインクルードします。(データベースのストレージモデルにマップします)。使用してこれを抑制できます。フィールドに基づいてモデルのフィールドに値を設定しようとします。モデルはそれらのフィールドも取得することを意味します。セカンダリインデックスを追加する場合など、これらのフィールドに関する追加情報を指定する必要が生じることがあります。他の場合には、ペイロードに含まれていないフィールドがモデル内に必要です。モデルのフィールド定義を指定できます。モデル定義の抜粋です。フィールドは明示的にここに設定されていますが、上記のように必須ではありません。定義も含まれています。タグを使用して、複数のフィールド定義をモデルに作成して指定できます。フィールドの別名も指定しました。モデルとフィールドの定義の両方にエイリアスを指定できます。テーブルにエイリアスを指定すると、データベース内のテーブルの名前が変更されます。機能を使用してモデルを生成します。一定の期待をしています。すべての自動配線をうまく機能させるには、あまり離れすぎてはいけません。モデルのリレーションは、メディアタイプで指定した暗黙的な関係と一致する必要があります。メディアタイプに実際に別のメディアタイプの属性があることを指定すると、リレーションを指定しています。反映されなければなりません。命名:キャメルケースでモデルに名前を付けます。スネークケースでフィールドに名前を付けます。常に命名とコンバージョンを使って正しいことをしようとしますが、この標準を維持することで、まだテストされていないエッジケースの助けになります。呼ばれるフォルダにあなたのモデルを生成します。追加することでこれを上書きすることができます。型であると予想しています。将来的に、非整数の主キーをサポートするかもしれません。対して広範にテストされています。サポートしている他のデータベースに対してもうまくいくはずですが、もしそうでなければバグを報告してください。よって生成されるメソッドは、主キーによるデータ操作のための基本的なケースメソッドです。将来のルックアップ関数をモデルの他のフィールドで追加することは可能です。プルリクエストは喜んで受け入れます。