ページの編集

Sails v1.0へのアップグレード

Sails v1.0 がリリースされました！このリリースでの変更点の概要と、アプリで活用できる可能性のある新機能について読み進めてください。

破壊的な変更に関する注意

このバージョンのSailsの開発中に、私たちが下した多くの決定は、後方互換性よりも優れた開発者エクスペリエンスを優先しました。このため、Sails 1.0へのアップグレードでは、以前のバージョンよりも多くの破壊的な変更に対処する必要があります。しかし、完了すれば、Sailsで使用している機能が、その作者やメンテナーが十分に理解し、ほぼ毎日使用しているものである可能性がはるかに高まります。

1.0の多くの破壊的な変更の背後にある哲学について詳しくは、Mike McNeilの詳細な説明をこちらでお読みください。

自動ツールを使用して既存のアプリをアップグレードする

既存のv0.12.x Sailsアプリをバージョン1.0にアップグレードする準備はできましたか？まず、最も一般的な移行タスクに役立つSails 1.0アップグレードツールを使用することをお勧めします。ツールを使用するには、まずnpm install -g sails@^1.0.0でSails 1.0をグローバルにインストールし、次にsails upgradeを実行します。ツールが実行されると、手動でアップグレードする必要がある残りの項目のリストを含むレポートが作成されます。

既存のアプリを手動でアップグレードする

以下のチェックリストは、ほとんどのアプリに影響を与える可能性のある変更を網羅しています。

このチェックリストに従っても、アプリの起動時にエラーや警告が表示される場合、または予期しないことが発生している場合は、このドキュメントに戻って、ページの下部をさらに確認してください。（さまざまなアプリコンポーネントをカバーするガイドのいずれかが該当する可能性があります。）

特にコンソールに表示されるエラーと警告に関しては、アップグレードプロセスをできるだけシームレスにするために多くの作業を行ってきました。ただし、行き詰まったり、以下の変更点について疑問が残る場合は、SailsコミュニティのGitterチャンネルにお気軽にお立ち寄りください。（会社でSails Flagshipを使用している場合は、Sailsコアチームとこちらで直接チャットすることもできます。）

要するにチェックリスト：バージョン1.0にアップグレードするときに必ず行う必要があること

アップグレードツールは、これらの項目の一部を支援するために最善を尽くしますが、アプリ固有のコードを代わりに変更することはありません！

• ステップ0：Nodeのバージョンを確認する
• ステップ1：フックをインストールして依存関係を更新する
• ステップ2：構成を更新する
• ステップ3：新しいブループリントAPI用にクライアント側のコードを変更する
• ステップ4：Waterline ORMの新しいリリースを採用する

ステップ0：Nodeのバージョンを確認してください！

アプリがv4より前のNodeバージョンをサポートする必要がある場合、Sails 1.0にアップグレードすることはできません。Sails 1.0はNode v0.xをサポートしなくなったためです。Sails 1.0でサポートされるNodeの最も古いバージョンはNode 4.xです。

ステップ1：フックをインストールして依存関係を更新する

Sails v1では、カスタムビルドが導入されています。これは、特定のコアフックがアプリの直接的な依存関係としてインストールされることを意味し、依存関係をより細かく制御できるようになり、npm install sailsの実行が大幅に高速化されます。そのため、最初に行う必要があるのは、使用しているコアフックをインストールすることです。（また、その際に、以下のリストに記載されている他の依存関係も更新してください。）

• アプリでORMフックが無効になっている場合を除き、npm install --save sails-hook-ormを使用して、sails-hook-ormパッケージをアプリにインストールします。
• アプリでソケットフックが無効になっている場合を除き、npm install --save sails-hook-socketsを使用して、sails-hook-socketsパッケージをアプリにインストールします。
• アプリでGruntフックが無効になっている場合を除き、npm install --save sails-hook-gruntを使用して、sails-hook-gruntパッケージをアプリにインストールします。
• データベースアダプターの最新バージョンをインストールします。たとえば、sails-mysqlを使用している場合は、npm install --save sails-mysql@latestを実行します。
• sails generate sails.io.jsで、sails.io.js websocketクライアントをアップグレードします。詳細については、下記の「Websockets」セクションを参照してください。

ステップ2：構成を更新する

Sails v1には、アプリ構成にいくつかの改善が加えられています。たとえば、lodashとasyncの自動インストールを任意のバージョンにカスタマイズできるようになり、ビューエンジンの構成構文がExpress v4+の構文と一致するようになりました。ただし、構成に対する最も重要な変更は、Sails v1の最もエキサイティングな新機能の1つであるデータストアに関連しています。データベースやその他の設定の構成を正しくアップグレードするために、以下の手順を注意深く読み、必要な変更を適用してください。

• （アプリでsails.config.globalsがfalseに設定されていない限り）config/globals.jsファイルを更新します
  • modelsとsailsをブール値（trueまたはfalse）に設定します。
  • asyncとlodashをそれぞれrequire('async')とrequire('lodash')、またはfalseに設定します。npm install --save lodashとnpm install --save asyncも必要になる場合があります。
• config/connections.jsで使用していないデータベース構成をコメントアウトします。以前のバージョンとは異なり、Sails 1.0は、モデルで実際に使用されているかどうかに関係なく、構成ファイルで参照されているすべてのデータベースアダプターをロードします。詳細については、データベース構成に関する移行ガイドセクションを参照してください。
• /csrfTokenルートは、CSRFを使用している場合、デフォルトではすべてのアプリに提供されなくなりました。アプリでこのルートを使用している場合は、config/routes.jsに'GET /csrfToken': { action: 'security/grant-csrf-token' }として手動で追加する必要があります。
• アプリがアクションシャドウルートに依存している場合（すべてのカスタムコントローラーアクションが自動的にルートにマッピングされる）、config/blueprints.jsファイルを更新して、actionsをtrueに設定する必要があります。この設定は、デフォルトでfalseになっています。
• アプリでCoffeeScriptまたはTypeScriptを使用している場合は、更新情報についてCoffeeScriptとTypeScriptのチュートリアルを参照してください。
• アプリでEJS以外のビューエンジンを使用している場合は、config/views.jsファイルで自分で構成する必要があり、プロジェクトでnpm install --save consolidateを実行する必要がある場合があります。詳細については、下記の「ビュー」セクションを参照してください。
• apiまたはconfigフォルダーとそのサブフォルダーにソースファイル以外のファイルが含まれている場合は、移動する必要があります。例外は、Markdown（.md）ファイルとテキスト（.txt）ファイルで、これらは引き続き無視されます。Sailsは、それらのフォルダー内の他のすべてのファイルをコードとして読み取ろうとするため、Javascript方言を選択する際の柔軟性が向上します（上記のCoffeeScriptとTypeScriptに関する注記を参照してください）。

ステップ3：新しいブループリントAPI用にクライアント側のコードを変更する

新しいエンドポイントが含まれるように拡張されただけでなく、クライアント側のコードを変更する必要があるかもしれない、ブループリントAPIに対するいくつかの小さな（しかし破壊的な）変更もあります。

• アプリでブループリントルートを使用している場合、いくつかの暗黙の「シャドウ」ルートでHTTPメソッド（別名動詞）が変更されたことに注意してください。
  • addのRESTfulブループリントルートアドレスがPOSTからPUTに変更されました。
  • updateのRESTfulブループリントルートアドレスがPUTからPATCHに変更されました。
• アプリがブループリントアクションからのデフォルトのソケット通知に依存している場合、これらのメッセージの構造を多少変更するパフォーマンス関連のアップグレードがあることに注意してください。
  • Sailsは、コレクションの新しいメンバーごとに個別のaddedTo通知を公開しなくなりました。これらの個々の通知は、1つの通知にまとめられるようになり、新しいメッセージには1つではなくIDの配列（addedIds）が含まれるようになりました。
  • Sailsは、コレクションの以前のメンバーごとに個別のremovedFrom通知を公開しなくなりました。Sailsは、これらの通知を1つの通知にまとめられるようになり、新しいメッセージには1つではなくIDの配列（removedIds）が含まれるようになりました。

ステップ4：Waterline ORMの新しいリリースを採用する

Waterline ORMの新しいリリース（v0.13）では、SQLトランザクションの完全なサポート、結果セット（別名「プロジェクション」）に属性を含めたり省略したりする機能、動的なデータベース接続、およびクエリ動作に対するより広範なきめ細かい制御が導入されています。また、安定性とパフォーマンスの大幅な見直しも含まれており、これには使用方法に対するいくつかの破壊的な変更が伴います。以下の箇条書きは、Waterlineのアップグレードで発生する可能性のある最も一般的な問題について説明しています。

• アプリが.create()、.createEach()、.update()、または.destroy()呼び出しからレコードを取得することに依存している場合、それらのメソッドでレコードをフェッチするようにモデル設定を更新する必要があります（または、個々の呼び出しに.fetch()をチェーンする必要があります）。詳細については、create()、.createEach()、.update()、および.destroy()の結果に関する移行ガイドセクションを参照してください。
• アプリがコレクションを変更するために.add()、.remove()、および.save()メソッドを使用することに依存している場合は、新しい.addToCollection、.removeFromCollection、および.replaceCollectionモデルメソッドを使用するように更新する必要があります。
• Waterlineクエリは、大文字と小文字の区別についてデータベースに依存するようになりました。これは、ほとんどのアダプターでクエリが大文字と小文字を区別するようになったことを意味します。以前はそうではありませんでした。大文字と小文字を区別しないクエリに慣れている場合は、予期しない結果になる可能性があります。MySQLなどのデータベースでこれを管理する方法の詳細については、大文字と小文字の区別のドキュメントを参照してください。
• Waterlineは、ネストされたcreateやupdateをサポートしなくなりました。この変更は、関連するブループリントにも適用されます。もしあなたのアプリがこれらの機能に依存している場合は、ネストされたcreateとupdateに関する移行ガイドのセクションを参照してください。
• もしあなたのアプリが.create()、.findOrCreate()、または.update()を使用してモデルの属性をnullに設定している場合、その属性の型をjsonに変更するか、nullの代わりに既存の属性型の基本値を使用する必要があります（例：数値の場合は0）。詳しくはバリデーションに関するドキュメントを参照してください。
• createブループリントのレスポンスは、find、findOne、update、およびdestroyからのレスポンスと同様に、完全にデータが入力された状態になりました。レコードの入力を抑制するには、ブループリント設定または特定ルートにparseBlueprintOptionsを追加してください。詳しくはブループリント設定のリファレンスを参照してください。
• createEachを使用して大量の行をデータベースに挿入している場合、ほとんどのアダプターのSails 1.0対応バージョンでは、createEachメソッドが1行あたり1クエリを使用する代わりに、単一のクエリを使用するように最適化されていることに注意してください。データベースによっては、リクエストごとのデータサイズ制限が適用される場合があります。詳しくは.createEach()のリファレンスページの下部にある注記を参照してください。
• 属性のsizeプロパティは、サポートされなくなりました。代わりに、columnTypeプロパティを使用してカラムサイズを指定できます。
• 属性のdefaultsToプロパティは、関数として定義できなくなりました。代わりに、デフォルト値をハードコードするか、defaultsToを完全に削除し、新しいレコードを作成する前に属性の適切な値を決定するようにコードを更新する必要があります。（これは、アクションでの.create()/.createEach()呼び出しの前、またはモデルのbeforeCreateで処理できます。）

その他の破壊的な変更

上記のアップグレードガイドでは、Sailsのコントリビューターがバージョン0.12からバージョン1.0に様々なアプリをアップグレードする際に遭遇した最も一般的なアップグレードの問題について説明しています。しかし、すべてのアプリは異なるため、以下の点も確認することをお勧めします。説明されているすべての変更が必ずしもあなたのアプリに適用されるとは限りませんが、一部は適用される可能性があります。

• reqの一部のプロパティとメソッドの動作が少し変更されました。
  • req.acceptedはreq.accepts()に置き換えられました。
  • req.acceptedLanguagesとreq.acceptsLanguage()は、req.acceptsLanguages()に置き換えられました。
  • req.acceptedCharsetsとreq.acceptsCharset()は、req.acceptsCharsets()に置き換えられました。
• ブループリントに関連する一部のreq.optionsプロパティはサポートされなくなりました。代わりに、新しいparseBlueprintOptionsメソッドを使用すると、ブループリントの動作を完全に制御できます。詳しくはブループリント設定のリファレンスを参照してください。
• defaultLimitおよびpopulateブループリント設定オプションはサポートされなくなりました。代わりに、新しいparseBlueprintOptionsメソッドを使用すると、ブループリントの動作を完全に制御できます。詳しくはブループリント設定のリファレンスを参照してください。
• .findOne()クエリメソッドは、sortおよびlimit修飾子をサポートしなくなり、指定された条件に複数のレコードが一致するとエラーをスローします。主キーのようなunique属性以外を条件として単一のレコードを見つけたい場合は、代わりに.find(<criteria>).limit(1)を使用してください（これは1つのアイテムの配列を返すことに注意してください）。
• autoPk、autoCreatedAt、およびautoUpdatedAtは、トップレベルのモデルプロパティとしてサポートされなくなりました。詳しくは、モデル設定の変更に関する移行ガイドのセクションを参照してください。
• 動的なファインダー（User.findById()など）は、モデルに自動的に追加されなくなりました。これらは、カスタムモデルメソッドとして自分で実装できます。
• モデルインスタンスメソッドはサポートされなくなりました。これにより、findクエリから返されるレコードは、モデルレコードインスタンスではなくプレーンなJavaScriptオブジェクトになります。
• カスタムの.toJSON()インスタンスメソッドはサポートされなくなりました。代わりに、モデルクラス（attributesディクショナリの外側）にcustomToJSONメソッドを追加してください。詳しくはモデル設定のドキュメントを参照してください。
• .toObject()インスタンスメソッドは、すべてのレコードに追加されなくなりました。モデルのcustomToJSONを実装するときは、_.omit()、_.pick()、または_.clone()を使用してレコードを複製するようにしてください。
• autoUpdatedAtタイムスタンプは、.update()の呼び出しで手動で更新できるようになりました（以前は、渡された属性値は無視されていました）。以前の動作は.save()の使用を容易にしましたが、これはサポートされなくなりました。必要に応じてupdatedAtを更新できます（ただし、通常はSailsに任せる必要があります！）。
• beforeValidateとafterValidateライフサイクルコールバックは存在しなくなりました。クエリにアクセスするには、他の多くのライフサイクルコールバックのいずれかを使用してください。
• afterDestroyライフサイクルコールバックは、単一のレコードを受け取るようになりました。afterUpdateコールバックと同じように動作するように正規化され、破棄されたすべてのレコードに対して1回ではなく、破棄されたレコードごとに1回関数を呼び出します。
• 多くのリソースフルPubSubメソッドが変更されました（完全なリストについては、下のPubSubセクションを参照してください）。もしあなたのアプリがブループリントによって提供される自動RPS機能のみを使用しており（RPSメソッドを直接呼び出さない場合）、更新は必要ありません。
• .find()モデルメソッドは、認識されない属性に提供された制約を自動的に強制しなくなりました。たとえば、Purchase.find({ amount: '12' })をブループリント経由で実行した場合（https://:1337/purchase?amount=12)、そのような "amount" 属性が存在しない場合、データベースに数値相当のレコード（12）が含まれていても、一致しません。（これは、MongoDBとsails-diskを使用している場合にのみ関連します。）これが原因で問題が発生する場合は、属性を数値として定義するか、（ブループリントを使用している場合）明示的なwhere句を使用してください（例：https://.com:1337/purchase?where={"amount":12}）。
• カスタムブループリントと関連するブループリントルート構文は削除されました。この機能は、カスタムアクション、ヘルパー、およびルートを使用して複製できます。詳しくは、下の「カスタムブループリントの置き換え」セクションを参照してください。
• ブループリントアクションのシャドウルートの末尾には、/:id?は含まれなくなりました。つまり、UserController.jsにtickleアクションがある場合、/user/tickle/:id?ルートは取得されなくなります（代わりに、/user/tickleのみになります）。これらのルートに依存しているアプリは、config/routes.jsファイルに手動で追加する必要があります。
• v0.12.xで非推奨になったsails.getBaseUrlは削除されました。なぜ削除されたのか、どのように置き換えるべきかについては、getBaseUrlに関するv0.12のドキュメントを参照してください。
• v0.12.xで非推奨になったreq.params.all()は削除されました。代わりにreq.allParams()を使用してください。
• v0.12.xで非推奨になったsails.config.dontFlattenConfigは削除されました。詳細については、dontFlattenConfigに関する元の注記を参照してください。
• req.param()とreq.allParams()の優先順位が変更されました。一貫して、path > body > query（つまり、URLパスパラメーターはリクエストボディパラメーターをオーバーライドし、リクエストボディパラメーターはクエリ文字列パラメーターをオーバーライドします）。
• req.validate()は削除されました。代わりにactions2を使用してください。
• デフォルトのres.created()レスポンスは削除されました。アプリでres.created()を直接呼び出しており、api/responses/created.jsファイルがない場合は、作成する必要があります。
  • 関連して、ブループリントのcreateアクションは、成功時に201ではなく200ステータスコードを返すようになりました。
• デフォルトのnotFoundおよびserverErrorレスポンスは、pathToView引数を受け入れなくなりました。これらは、404または500ビューの提供のみを試みます。異なるビューでこれらのレスポンスを呼び出す必要がある場合は、アプリにapi/responses/notFound.jsまたはapi/responses/serverError.jsファイルを追加して、レスポンスをカスタマイズできます。
• デフォルトのbadRequestまたはforbiddenレスポンスはビューを表示しなくなりました。まだapi/responses/badRequest.jsおよびapi/responses/forbidden.jsファイルがない場合は、それらを追加し、ビューファイルを表示する場合はカスタムコードを記述する必要があります。
• connect-flashミドルウェアが削除されました（そのため、req.flash()はデフォルトでは利用できなくなります）。req.flash()の使用を継続する場合は、アプリフォルダーでnpm install --save connect-flashを実行し、手動でミドルウェアを追加してください。
• POST /:model/:idブループリントのRESTfulルートは削除されました。アプリがこのルートに依存している場合は、config/routes.jsに手動で追加し、カスタムアクションにバインドする必要があります。
• handleBodyParserErrorミドルウェアは削除されました。代わりに、Skipper body parserに独自のonBodyParserErrorメソッドが追加されました。
  • もしミドルウェアの順序をカスタマイズしている場合は、配列からhandleBodyParserErrorを削除する必要があります。
  • handleBodyParserErrorをオーバーライドしている場合は、代わりにbodyParserを、onBodyParserErrorオプションにエラー処理ロジックを含む、独自のカスタマイズされたバージョンのSkipperでオーバーライドする必要があります。
• methodOverrideミドルウェアは削除されました。アプリがこのミドルウェアを利用している場合は、
  • npm install --save method-override
  • sails.config.http.middleware.order配列（config/http.js内）に、routerの前のどこかにmethodOverrideが含まれていることを確認してください。
  • methodOverride: require('method-override')()をsails.config.http.middlewareに追加してください。
• routerミドルウェアは上書きできなくなりました。 代わりに、外部および内部（別名「仮想」）リクエストの両方のルーティングにExpress 4ルーターが使用されます。ルーターの前後にどのミドルウェアを追加するかを区切るために、sails.config.http.middleware.orderにrouterエントリを含めることは依然として重要です。
• クエリ修飾子のlessThan、lessThanOrEqual、greaterThan、およびgreaterThanOrEqualが削除されました。代わりに、短縮バージョン（<、<=、>、>=）を使用してください。
• find oneおよびfindブループリントアクションは、属性をポピュレートしないことを指定するために、populate=ではなくpopulate=falseを受け入れるようになりました。
• addおよびremoveブループリントアクションは、クエリ文字列またはリクエストボディで渡すのではなく、追加または削除する子レコードの主キーをURLの一部として指定する必要があります。
• destroyブループリントアクションは、クエリ文字列またはリクエストボディで渡すのではなく、削除するレコードの主キーをURLの一部として指定する必要があります。
• sails.config.session.routesDisabled設定が変更され、関数であるsails.config.session.isSessionDisabled()になりました。isSessionDisabled()の構成の詳細については、config/session.jsドキュメントを参照してください。
• Waterlineメソッドの実験的な「switchback-style」の使用はサポートされなくなりました。関数コールバックのみをWaterlineモデルメソッドで使用できます。
• 実験的なcreate自動マイグレーションスキームはサポートされなくなりました。本番データベースの移行を処理するには、Knexなどの移行ツールを使用することを強くお勧めします。
• 実験的なforceLoadAdapterデータストア設定はサポートされなくなりました。代わりに、Sailsが起動するたびに、config/datastores.js（以前のconfig/connections.js）で参照されているすべてのアダプターが自動的にロードされます。
• 実験的なusageルートオプションが削除されました。ルートパラメータの検証はコントローラーコードで実行することをお勧めします。
• 実験的な「関連アイテム」ブループリントシャドウルートが削除されました。これらはGET /user/1/pets/2のようなルートであり、その機能は、より明確なルートGET /pets/2を使用するだけで複製できます。
• モデルクラスの実験的な.validate()メソッド（例：User.validate()）が完全にサポートされるようになりましたが、その使い方が変更されました。詳細については、.validate()ドキュメントを参照してください。
• モデルクラスの内部表現における属性の順序が変更されました（関連付けられた属性は一番下にソートされるようになりました）。これにより、migrate: 'alter'を使用して作成されたテーブルの列が、以前のバージョンのWaterlineとは異なる順序になるため、アプリケーションで列の順序が重要な場合は注意してください。念のためですが、自動マイグレーションは、アプリを構築するときにスキーマを設計するのに役立つことを目的としています。列名、タイプ（指定されている場合は文字セット/エンコーディングを含む）、および一意性設定を除き、物理データベース列の詳細に関して一貫性が保証されているわけではありません。
• _configを使用してコントローラーをモデルにリンクすることはできなくなります。これはサポートされている機能ではありませんでしたが、一部のプロジェクトでは、モデルのブループリントアクションにマッピングされたURLを変更するために使用されていました。代わりに、restPrefixを使用してください。
• find()、destroy()、およびupdate()メソッドは、undefined属性を無視します。これらのメソッドは、検索条件からundefined属性を削除します。たとえば、User.update({id: undefined}).with({ firstName: 'Finn'})はすべてのユーザーレコードを更新します。これについて詳しくは、このGithubの問題をご覧ください。

データベース構成の変更

• sails.config.connections設定は非推奨になり、sails.config.datastoresが推奨されます。sails.config.connectionsが構成されたままのアプリを起動すると、config/connections.jsのmodule.exports.connectionsをmodule.exports.datastoresに変更するだけで回避できる警告が表示されます。混乱しないように、ファイル名をconfig/datastores.jsに変更することも推奨されます。
• sails.config.models.connection設定は非推奨になり、sails.config.models.datastoreが推奨されます。上記と同様に、config/models.jsのプロパティの名前を変更するだけで、警告をオフにするのに十分です。
• すべてのアプリには、sails-diskアダプターの組み込みバージョンを使用するように構成されたデフォルトのデータストア（defaultという名前）が用意されています。Sails 1.0では、sails.config.models.datastoreのデフォルト値は（localDiskDbではなく）defaultです。モデルのデフォルトデータストアを設定する推奨される方法は、config/datastores.jsのdefaultキーの下に目的の構成を追加し、config/models.jsのdatastoreキーを未定義のままにすることです（たとえば、datastoreをmyPostgresqlDbに設定し、myPostgresqlDbキーをconfig/datastores.jsに追加するという以前のアプローチとは異なります）。これにより、さまざまな環境で使用されるデータストアを簡単に変更できます（たとえば、config/env/production.jsでdefaultデータストアの構成を変更するなど）。
• アプリで構成されたすべてのデータストアは、実行時にロードされます（少なくとも1つのモデルで使用されているデータストアのみをロードするのではなく）。これは、個々のモデルのコンテキスト外でデータストアを使用できるという利点がありますが、Sailsが起動するときに特定のデータベースに接続したくない場合は、そのデータストア接続構成をコメントアウトする必要があることを意味します！

ネストされた作成と更新

• モデルメソッドの.create()、.update()、および.add()は、新しい親または既存の親に直接リンクする新しい「子」レコードの作成をサポートしなくなりました。たとえば、Userモデルがpetという属性を介してAnimalモデルへの単数形の関連付けを持っている場合、petを真新しいAnimalの値（別名「ネストされた作成」）を表す辞書に設定することはできません。代わりに、最初に新しいAnimalを作成し、その主キーを使用して、新しいUserを作成するときにpetを設定します。
• 同様に、create、update、およびaddブループリントアクションは、ネストされた作成をサポートしなくなりました。
• モデルメソッドの.update()とその関連するブループリントアクションは、複数形の関連付け全体を置き換えることをサポートしなくなりました。レコードが「1対多」または「多対多」の関連付けを介して1つ以上の他のレコードにリンクされており、それをまったく異なるレコードセットにリンクしたい場合は、.replaceCollection()モデルメソッドまたはreplaceブループリントアクションを使用してください。

モデル構成の変更

tl;dr

モデルからautoPK、autoCreatedAt、およびautoUpdatedAtプロパティを削除し、config/models.jsファイルに以下を追加します

attributes: {
    createdAt: { type: 'number', autoCreatedAt: true, },
    updatedAt: { type: 'number', autoUpdatedAt: true, },
    id: { type: 'number', autoIncrement: true}, // <-- for SQL databases
    id: { type: 'string', columnName: '_id'}, // <-- for MongoDB
  }

autoPKトップレベルプロパティはサポートされなくなりました

このプロパティは、以前は、Waterlineがモデルの主キーとしてid属性を作成するかどうかを示すために使用されていました。Sails v1.0 / Waterline 0.13以降、Waterlineはバックグラウンドで属性を作成しなくなります。代わりに、id属性を明示的に定義する必要があります。モデルの主キーとして使用する必要がある属性の名前を設定できる、primaryKeyという新しいトップレベルのモデルプロパティもあります。この値はすべてのモデルでデフォルトでidに設定されるため、通常は自分で設定する必要はありません。

autoUpdatedAtおよびautoCreatedAtモデル設定は、属性レベルのプロパティになりました

これらのプロパティは、以前は、WaterlineがモデルのcreatedAtおよびupdatedAtタイムスタンプを作成するかどうかを示すために使用されていました。Sails v1.0 / Waterline 0.13以降、Waterlineはバックグラウンドでこれらの属性を作成しなくなります。代わりに、それらを使用する場合は、createdAtおよびupdatedAt属性を明示的に定義する必要があります。属性定義にautoCreatedAt: trueまたはautoUpdatedAt: trueを追加することで、レコードが作成または更新されるたびに、その属性を現在のタイムスタンプに設定するようにWaterlineに指示できます。これらの属性のタイプに応じて、タイムスタンプは次の2つの形式のいずれかで生成されます

• type: 'string'の場合、これらのタイムスタンプはSails 0.12と同じ方法で、タイムゾーンに依存しないISO 8601 JSONタイムスタンプ文字列（例：'2017-12-30T12:51:10Z'）として保存されます。フロントエンドコードがタイムスタンプを文字列として依存している場合は、これをstringに設定することが重要です。
• type: 'number'の場合、これらのタイムスタンプはJSタイムスタンプ（1970年1月1日午前0時UTCからのミリ秒数）として保存されます。

さらに、任意の属性に対して、Waterlineの条件のwhere句内、または新しいレコードとして、または.update()クエリで設定する値の中にnew Date()を制約として渡すと、これらの同じルールが属性のタイプに基づいて適用されます。属性がtype: 'json'の場合、後者のアプローチを使用します。

.create()、.createEach()、.update()、および.destroy()の結果の変更

Sails v1.0 / Waterline 0.13以降、.create()、.createEach()、.update()、および.destroy()からのデフォルトの結果が変更されました。

より優れたパフォーマンスと簡単なスケーラビリティを促進するために、.create()は作成されたレコードを返さなくなりました。同様に、.createEach()は作成されたレコードの配列を返さなくなり、.update()は更新されたレコードの配列を返さなくなり、.destroy()は削除されたレコードを返さなくなりました。代わりに、.exec()コールバックへの2番目の引数はundefinedになります（または、プロミスを使用している場合は.then()への最初の引数）。

これにより、不要なfindクエリが削除され、アプリの効率が向上し、.update()および.destroy()を使用して、下位レベルのネイティブクエリにフォールバックするのではなく、大規模なデータセット内の多数の異なるレコードを変更できるようになります。

fetchメソッドを使用することで、単一のクエリに対して作成または変更されたレコードを返すようにアダプターに指示できます。例:

Article.update({
  category: 'health-and-wellness',
  status: 'draft'
})
.set({
  status: 'live'
})
.fetch()
.exec(function(err, updatedRecords){
  //...
});

アプリのすべてのクエリを変更するのが大変だと思われる場合は、一時的な便宜を利用できます。既存のアプリのアップグレードプロセスを容易にするために、アプリのすべての.create()/.createEach()/.update()/.destroy()クエリに対して作成/更新/削除されたレコードをフェッチするようにSails/Waterlineに指示できます。config/models.jsでアプリ全体のモデル設定を編集するだけです

fetchRecordsOnUpdate: true,
fetchRecordsOnDestroy: true,
fetchRecordsOnCreate: true,
fetchRecordsOnCreateEach: true,

以上です！ただし、パフォーマンスを向上させ、アプリを将来に対応させるには、すべての.create()、.createEach()、.update()、および.destroy()呼び出しを確認し、可能な場合は.fetch()を追加する必要があります。これらのモデル設定のサポートは、最終的にSails v2で削除されます。

Waterline条件の使用の変更

• パフォーマンス上の理由から、Sails v1.0 / Waterline 0.13以降、Waterlineのモデルメソッドに渡される条件は、ほとんどの場合、インプレースで変更されます（Sails/Waterline v0.12では、必ずしもそうではありませんでした）。
• 集計句 (sum, average, min, max, および groupBy) は、criteria ではサポートされなくなりました。代わりに、新しいモデルメソッド .sum() および .avg() を参照してください。
• limit および skip の変更
  • limit: 0 は、もはや limit: undefined と同じ動作をしなくなりました。無限の結果に一致する代わりに、0個の結果に一致するようになりました。
  • limit に < 0 を指定することは避けてください。依然として無視され、limit: undefined のように動作しますが、コンソールに非推奨の警告ログが表示されるようになりました。
  • skip: -20 は、もはや skip: undefined と同じ動作をしなくなりました。結果を0個スキップする代わりに、エラーが発生して実行を拒否するようになりました。
  • limit は Number.MAX_SAFE_INTEGER より小さくなければなりません（...ただし、1つの例外があります。互換性/利便性のため、Infinity は許容され、自動的に Number.MAX_SAFE_INTEGER に正規化されます）。
  • skip は Number.MAX_SAFE_INTEGER より小さくなければなりません。

混合 where 句のサポート変更

混合 where 句を持つ criteria ディクショナリは、もはやサポートされません。たとえば、以下の代わりに

{
  username: 'santaclaus',
  limit: 4,
  select: ['beardLength', 'lat', 'long']
}

以下を使用する必要があります。

{
  where: { username: 'santaclaus' },
  limit: 4,
  select: ['beardLength', 'lat', 'long']
}

{ username: 'santaclaus' } を { where: { username: 'santaclaus' } } の省略形として使用できることに注意してください。ただし、制約（例：username）と並んで、他のトップレベルの criteria 句（limit など）を混合することはできません。

Waterline のチェーン可能な遅延オブジェクトを使用して criteria を構築している場合、これについては心配する必要はありません。これはすでに処理済みです。

セキュリティ

Sails 1.0 で作成された新しいアプリには、個別の config/cors.js および config/csrf.js ファイルの代わりに、config/security.js ファイルが含まれるようになります。以前のバージョンから移行するアプリは、以下のアップグレードを実行すれば、既存のファイルを保持できます。

• config/cors.js 内の module.exports.cors を module.exports.security.cors に変更します。
• リファレンス > 設定 > sails.config.security に新たに文書化された名前に一致するように、CORS 設定の名前を変更します。
• config/csrf.js 内の module.exports.csrf を module.exports.security.csrf に変更します。この値は、単に true または false になりました。他の CSRF オプションはサポートされていません（下記参照）。
• sails.config.csrf.routesDisabled は、もはやサポートされません。代わりに、CSRF で保護したくない config/routes.js 内のルートに csrf: false を追加します。たとえば、

'POST /some-thing': { action: 'do-a-thing', csrf: false },

• sails.config.csrf.origin は、もはやサポートされません。代わりに、カスタム CORS 設定を CSRF トークンルート構成に直接追加できます。たとえば、

'GET /csrfToken': {
  action: 'security/grant-csrf-token',
  cors: {
    allowOrigins: ['http://foobar.com', 'https://owlhoot.com']
  }
}

• sails.config.csrf.grantTokenViaAjax は、もはやサポートされません。この設定は、CSRF トークンを許可するルートのオン/オフを切り替えるために使用されていました。Sails 1.0 では、config/routes.js ファイルに手動でルートを追加します（上記参照）。AJAX を介して CSRF トークンを許可したくない場合は、そのルートを config/routes.js から削除するだけです。

ビュー

最大限の柔軟性を実現するために、Consolidate は Sails にバンドルされなくなりました。EJS 以外のビューエンジンを使用している場合は、Consolidate をアプリの直接の依存関係としてインストールすることをお勧めします。次に、config/views.js でビューエンジンを構成できます。以下を参照してください。

extension: 'swig',
getRenderFn: function() {
  // Import `consolidate`.
  var cons = require('consolidate');
  // Return the rendering function for Swig.
  return cons.swig;
}

Sails 1.0 では、ビューエンジンにカスタム構成を追加することが非常に簡単になりました。

extension: 'swig',
getRenderFn: function() {
  // Import `consolidate`.
  var cons = require('consolidate');
  // Import `swig`.
  var swig = require('swig');
  // Configure `swig`.
  swig.setDefaults({tagControls: ['{?', '?}']});
  // Set the module that Consolidate uses for Swig.
  cons.requires.swig = swig;
  // Return the rendering function for Swig.
  return cons.swig;
}

レイアウトの組み込みサポート は、デフォルトの EJS ビューでは引き続き機能しますが、他のビューエンジン（たとえば、Handlebars や Ractive）のレイアウトサポートは Sails 1.0 にバンドルされていません。

リソースフル PubSub

• 非推奨の backwardsCompatibilityFor0.9SocketClients 設定を削除しました。
• 非推奨の .subscribers() メソッドを削除しました。
• 非推奨の "firehose" 機能を削除しました。
• 0.9.x ソケットクライアント API のサポートを削除しました。
• 次のリソースフル pubsub メソッドも削除されました。
  • .publishAdd()
  • .publishCreate()
  • .publishDestroy()
  • .publishRemove()
  • .publishUpdate()
  • .watch()
  • .unwatch()
  • .message()

削除されたメソッドの代わりに、新しい .publish() メソッド、または低レベルの sails.sockets メソッドを使用する必要があります。.message() とは異なり、.publish() はレコード ID を含むエンベロープでデータをラップしないため、ID が重要な場合は、データの一部として自分で ID を含める必要があることに注意してください。たとえば、Sails v0.12.x では、User.message(123, {owl: 'hoot'}) を使用すると、次の通知がクライアントにブロードキャストされていました。

{
  verb: 'messaged',
  id: 123,
  data: {
    owl: 'hoot'
  }
}

対照的に、Sails v1.0 では、User.publish(123, {owl: 'hoot'}) は単に以下をブロードキャストします。

{
  owl: 'hoot'
}

カスタムブループリントの置き換え

すぐに使用できる機能として、api/blueprints/ にファイルを追加して、すべてのモデルのブループリントアクションとして自動的に使用されるようにすることはできなくなりました。ただし、これは sails-hook-custom-blueprints をインストールすることで簡単に複製できます。

Express 4

Sails 1.0 には、内部の Express サーバーがバージョン 3 からバージョン 4 に更新されています（@josebaseba による素晴らしい作業のおかげです）。この変更は主に Sails フレームワークの保守性に関するものであり、アプリには透過的であるはずです。ただし、注意すべき点がいくつかあります。

• 404、500、および startRequestTimer ミドルウェアは、すべての Sails アプリに組み込まれるようになり、sails.config.http.middleware.order 配列から削除されました。アプリでオーバーライドされた 404 または 500 ハンドラーがある場合は、代わりにそれぞれ api/responses/notFound.js および api/responses/serverError.js をオーバーライドする必要があります。
• Express 3 用に特別に設計されたセッションミドルウェア（たとえば、非常に古いバージョンの connect-redis または connect-mongo）は機能しなくなるため、より新しいバージョンにアップグレードする必要があります。
• sails.config.http.customMiddleware 機能は、Sails 1.0 で非推奨になりました。当面は機能しますが、今後のリリースで削除される可能性があります。customMiddleware を使用して Express アプリを直接変更する代わりに、通常の (req, res, next) ミドルウェアを使用してください。たとえば、次のようなものを置き換えることができます。

customMiddleware: function(app) {
  var passport = require('passport');
  app.use(passport.initialize());
  app.use(passport.session());
}

次のようなものに置き換えることができます。

var passport = require('passport');
middleware: {
  passportInit: passport.initialize(),
  passportSession: passport.session()
},

passportInit および passportSession を config/http.js の middleware.order 配列に挿入してください。

レスポンスメソッド

• .jsonx() は非推奨です。api/responses にまったくカスタマイズしていないファイルがある場合は、それらを削除して、Sails のデフォルトのレスポンスを機能させることができます。api/responses に保持したいファイルがある場合は、それらのファイル内の res.jsonx() のすべての出現箇所を res.json() に置き換えてください。
• res.negotiate() は非推奨です。代わりに、res.serverError()、res.badRequest()、または カスタムレスポンス を使用してください。

i18n

Sails 1.0 は、i18n の使用から、軽量の i18n-2 モジュールに切り替わります。ほとんどのユーザーは、アプリに違いがないはずです。ただし、sails.config.i18n.updateFiles オプションを使用している場合は、これがもはやサポートされていないことに注意してください。代わりに、ロケールファイルは、開発モードでは常に更新され、本番モードでは決して更新されません。これが問題である場合、または i18n モジュールの一部の機能が見つからない場合は、sails-hook-i18n をインストールして、Sails 1.0 より前の機能に戻すことができます。

i18n 機能の使用により、アップグレード中に 0.12 アプリケーションで問題が発生する場合は、#4343 で、より多くのトラブルシューティングのヒントを参照してください。

WebSockets

websockets を使用するすべての Sails 1.0 プロジェクトは、最新の sails-hook-sockets 依存関係をインストールする必要があります (npm install --save sails-hook-sockets)。このバージョンの sails-hook-sockets は、いくつかの点で以前のバージョンとは異なります。

• デフォルトの transports 設定は、単に ['websocket'] です。ほとんどの本番環境のデプロイメントでは、アプリを websocket トランスポートに制限することで (['polling', 'websocket'] を使用するのではなく)、セッションに関する問題を回避できます (詳細については、1.0 より前の スケーリングガイドのメモ を参照してください)。sails.io.js websocket クライアントを使用している場合、アプリを新しい websocket 設定と互換性を持たせる最も簡単な方法は、sails generate sails.io.js で新しい sails.io.js バージョンをインストールすることです。そのパッケージの最新バージョンも、デフォルトで「websocket のみ」のトランスポート戦略になります。フロントエンドコードおよび config/sockets.js ファイルで transports 設定をカスタマイズしている場合は、両方の場所の値が一致するように引き続き確認する必要があります。
• 最新の sails-hook-sockets フックは、新しいバージョンの Socket.io を使用します。完全な更新については、Socket.io の変更ログ を参照してください。ただし、ソケット ID にデフォルトで /# がプレフィックスとして付加されなくなったことに注意してください。

Grunt

以前は Sails コアの一部だった Grunt タスク管理機能は、個別の sails-hook-grunt モジュールに移動されました。既存のアプリは、npm install --save sails-hook-grunt を実行するだけで Grunt を引き続き使用できます。ただし、アプリの Gruntfile.js を変更することで、sails-hook-grunt には、以前はプロジェクトレベルでインストールする必要があったすべての grunt-contrib モジュールが含まれているという事実を利用できます。新しい Gruntfile.js には、以下が含まれています。

module.exports = function(grunt) {

  var loadGruntTasks = require('sails-hook-grunt/accessible/load-grunt-tasks');

  // Load Grunt task configurations (from `tasks/config/`) and Grunt
  // task registrations (from `tasks/register/`).
  loadGruntTasks(__dirname, grunt);

};

アプリで Gruntfile をカスタマイズしていないと仮定すると、Gruntfile.js をそのコードに置き換えて、安全に次を実行できます。

npm uninstall --save grunt-contrib-clean
npm uninstall --save grunt-contrib-coffee
npm uninstall --save grunt-contrib-concat
npm uninstall --save grunt-contrib-copy
npm uninstall --save grunt-contrib-cssmin
npm uninstall --save grunt-contrib-jst
npm uninstall --save grunt-contrib-less
npm uninstall --save grunt-contrib-uglify
npm uninstall --save grunt-contrib-watch
npm uninstall --save grunt-sails-linker
npm uninstall --save grunt-sync
npm uninstall --save grunt-cli

これらの依存関係をプロジェクトから削除します。

トラブルシューティング

起動時に v0.12 がまだ表示されますか？

プロジェクトに sails がローカルにインストールされていること、およびコマンドラインツールの v1 バージョンを使用していることを確認してください。

v1.0 をグローバルにインストールするには、npm install sails@^1.0.0 -g を実行します。特定の Sails アプリ用にインストールするには、そのアプリのディレクトリに cd し、npm install sails@^1.0.0 --save を実行します。（ローカルにインストールした後、必要なフックも必ずインストールしてください。上記を参照してください）。