Mongoose: 新機能：仮想非同期

現在、私は汚い方法を使用しています：

User.virtual('password').set(function(v) {
  this.encryptedPassword = v
})

User.pre('validate', function preValidate(next) {
  return this.encryptPassword().then(next)
})

User.method('encryptPassword', async function encryptPassword() {
  this.passwordSalt = await encryptor.salt()
  this.encryptedPassword = await encryptor.hash(
    this.encryptedPassword,
    this.passwordSalt
  )
})

+1

+1

コードに非常に優れたアイデアがいくつかあります。この問題は何度か見られましたが、調査する時間があまりありませんでした。 私はこのアイデアが好きですが、次のリリースを検討します

問題は..使用構文はどのように見えるかです。

await (user.password = 'some-secure-password');

これは機能しません。

ECMA262 12.15.4によると、 user.password = 'some-secure-password'の戻り値は_rval_である必要があります。この場合、 'some-secure-password'です。

あなたはの戻り値持つことが提案されているsomeVar = object可能Promise 、とによると、このスレッド、および上記のリンクES262の仕様、それは「ESセマンティクスの深い違反。」

さらに、便利な関数を持つという単なる目的のためにそのようなセマンティック違反の問題を実装しようとすることは、特にマングースコードベース全体にとってあらゆる種類の悪いことを意味する可能性があるため、かなり悪い考えです。

どうしてあなたはただやらないのですか：

const hashPassword = require('./lib/hashPassword');

const password = await hashPassword('some-secure-password');
User.password = password; // This is completely normal.

このような単純なワンライナーの場合、文字通りasyncセッターを作成する必要はありません。これは最初から行うべきではありません。

これを行うこともできます：

User.methods.setPassword = async function (password) {
  const hashedPassword = await hashPassword(password);
  this.password = hashedPassword;
  await this.save();
  return this;
};

const myUser = new User();
await myUser.setPassword('mypassword...');

なぜ仮想化やフックの事前保存などを行うのに苦労するのかわかりません...

@heisianに同意します。 これは私にとって機能/ APIの肥大化のように感じます。 ここでは、インスタンスメソッドを使用する代わりの方法がどのように不便であるかわかりません。 しかし、これにかなり主要な構文サポートを追加することは、間違いなく肥大化したように感じます。

このような非常に単純な機能が必要です。

User.virtual('password').set((value, done) => {
  encryptValueWithAsyncFunction
    .then(response => done(null, value))
    .catch(reason => done(reason))
  ;
})

@gcanuあなたは私が投稿したものを完全に無視しています、あなたが提案しているものは代入呼び出しからPromiseを返し、それはJavascript / ECMA262仕様を完全に破ります。 コードスニペットが機能するには、セッター関数がPromiseである必要があります。これは、定義上、仕様ごとに許可されておらず、とにかく機能しません。

ただ行うことの何が問題になっていますか：

await User.setPassword('password');

???

あなたが前に見たことがない場合、これは機能しません：

await (User.password = 'password');

@ vkarpov15これはマングース固有の問題ではなく、現在のECMAScript仕様の有効性に疑問を投げかけています。 この「機能リクエスト」は閉じる必要があります...

以下のコードは非常に悪い考えです！ 設定されたパスワードにsave操作が含まれるのはなぜですか？

User.methods.setPassword = async function (password) {
  const hashedPassword = await hashPassword(password);
  this.password = hashedPassword;
  await this.save();
  return this;
};

const myUser = new User();
await myUser.setPassword('mypassword...');

マングースはより現代的でよりエレガントなものを必要としています。

@heisianわかりました、私の間違い、私はセッターの使用の世話をしませんでした...

@heisian Plzは、 https： //github.com/Automattic/mongoose/blob/master/lib/virtualtype.jsを参照して

現在、Mongoose IMPLでは、 getterまたはsetterは関数を登録してから呼び出すだけで、 https： //tc39.github.io/ecma262/#sec-assignment-operators-runtime-semanticsではありませんhttps://github.com/tc39/ecmascript-asyncawait/issues/82。 それは違います。

したがって、plzはこのリクエストを開きます。

@fundon 、これを教えてください：仮想セッターをどの程度正確に呼び出しますか？ 使い方を教えてください。 asyncを使用している場合は、promiseで処理する必要があります。 元の例では、セッター/代入呼び出しのどこにもawaitは表示されていません。

私のサンプルコードは単なる例です...これも簡単に行うことができます：

User.methods.setPassword = async function (password) {
  const hashedPassword = await hashPassword(password);
  this.password = hashedPassword;
  return this;
};

const myUser = new User();
await myUser.setPassword('mypassword...');
await myUser.save();

明らかに..

あなたの例は私にとって良い方法ではありません。

私が欲しい

await new User({ password }).save()

よりシンプルでエレガントなモードでパスワードをハッシュします。

どうして？ 数行のコードを節約できますか？ その理由は、すべての余分な作業を正当化し、コードベースへの変更を壊す可能性があることを正当化するのに十分ではありません。

また、どのように表現しても、Mongooseの内部で行われているのはセッターであり、非同期/待機することはできません。

@heisianに同意しません。 マングースには古いものが多すぎます。 マングースはリファクタリングが必要です！
マングースには現代性が必要です。

この問題が解決された場合。 マングースをフォークし、リファクタリングします！ さよなら！

素晴らしい！ それがオープンソースのポイントです。 どうぞ、トリミングされたバージョンでフォークを作成してください。それは私たち全員にとって良いことです。

await (User.password = 'password');が必要になる心配はまったくありません。 唯一の本当の欠点は、 user.password = 'password';は、何らかの非同期操作が発生していることを意味するため、 user.passwordSaltが設定されないことです。 それがフックにどのように関連するかも興味深い質問です。 pre('validate')またはpre('save')フックがある場合、 user.password非同期操作が完了するまで待つ必要がありますか？

私はこの問題を手に負えないで却下するつもりはありません。 .save() 、 .find()などの背後にある非同期動作を統合することには多くの価値があります。APIの他の部分とうまく適合することを確認する必要があります。

今日、非同期ゲッターとセッターは私にとって非常に重要です。 独自の暗号化方法でフィールドを復号化/暗号化するために、ゲッターとセッターからHTTPリクエストを送信する必要がありますが、現在、それを行う方法はありません。 あなたはそれを達成する方法についての考えを持っていますか？

@gcanu私はそれらをメソッドとして実装するだけです

前述の理由と、必要な非同期操作を簡単に処理する方法があるという事実のために、 async動作を統合する背後にあるユーティリティは見当たりません。繰り返しますが、 await (User.password = 'password')はECMAScriptの規則に違反します。それが困難になり、優雅に実装する価値がないことを保証します...

そうです、そのパターンは私たちが実装するものではありません。 保存する前に非同期仮想が解決するのを待つという考えは興味深いものです。

toJSON({virtuals: true})実装に気に入っています。 dbに対して他のクエリを実行することによって取得する仮想フィールドの一部。これは、シリアル化した後でのみ実行したいものです。

@gabzimは、JSON.stringifyが

そうそう、理にかなっている、ありがとう@ vkarpov15

getコールバック内でクエリを作成することをお勧めしますか？
これは場合によっては役立つと思います。

Github URLパスのように、ドキュメントをネストできるWebページ（またはドキュメント）のフルパスを取得したいとします。

const Doc = require('./Doc.js');
//...
subDocSchema.virtual('fullpath').get(async function(){
    const doc = await Doc.findById(this.doc); //doc is a Doc ref of type _id
    return `/${ doc.path }/${ this.path }`
})

ここでは、クエリ操作が非同期であるため、async / awaitを使用する必要があります。

この場合、 @ JulianSotoは、仮想ではなくメソッドを使用することをお勧めします。 仮想を使用する主な理由toJSON()とtoObject()は同期しているため、非同期仮想を処理しません。

私もこれのユースケースに遭遇しました。私は良い解決策を考え、アイデアに対して非常にオープンであり、セッターのセマンティクスを壊さないことに同意しようとしています。

JSONパッチセットをマングースモデルに自動的に適用するユーティリティを作成しました。 ディープパスを使用した自動入力をサポートします： https ：

アイデアは、いくつかのルールと組み合わせると、 https ：

私の計画では、単純な割り当てが機能しない場合は、仮想を使用することです。 パッチが適用されると、仮想は必要なものをすべて取得します。これにより、インターフェイスオブジェクトを実際のマングースモデル/データベースオブジェクトとは異なるものにすることができます。

たとえば、「payment_methods」で「add」操作をサポートするUserオブジェクトがあります。 支払い方法の追加は、配列への直接の追加ではありません。支払いトークンを使用したプロセッサへの呼び出し、支払い方法トークンの取得、モデルへの別の方法での保存などです。

しかし、インターフェースモデルである概念モデルにJSONパッチ「add」opでパッチを適用できるようにしたいと思います。

非同期セッターがないと、これは機能しません。 より良いアイデアがない限り、唯一のオプションは、mongoose-json-patchにパス、ops、およびmongooseメソッド間のある種のマッピングをオプションとして受け入れることだと思いますか？

@claytongulickなぜ、非同期操作でawaitではなく非同期セッターが必要で、同期的に設定する必要があるのですか？

@ vkarpov15単にtoObject()とtoJSON()非同期にして、 toObjectSync()とtoJSONSync()関数を導入するのはどうですか？ Syncバリアントは、単にasync仮想をスキップする必要があります。 （このパターンはどこかのマングースで使用されていることを覚えているので、それほど奇妙なことではありません。）

私のユースケースは次のようなものです。別のモデルでfind()を実行する仮想を持つスキーマがあります（単にIDを入力するよりも少し複雑です）。 もちろん、保存/削除フックを使用してメインモデルに必要なものを非正規化することはできますが、それには多くの保守コストが伴います（この特定のケースでは、パフォーマンス上の利点は本当に必要ありません）。 ですから、私のためにそれを行うための仮想を持っているのは自然なことです。

JSON.stringify()は非同期toJSON()サポートしていないため、残念ながらtoJSONSync()アイデアは機能しません。

find()はかなり複雑だとおっしゃっていましたが、念のため、

また、非同期仮想にはセッターがありますか、それともゲッター

この問題を抱えている人のための解決策：

セッターだけが非同期の場合、私は解決策を見つけました。 少し汚れていますが、問題なく動作しているようです。
アイデアは、コールバックプロップとしてpromiseリゾルバーを含むオブジェクトと設定する仮想プロパティを仮想セッターに渡すことです。 セッターが完了すると、コールバックが呼び出されます。これは、オブジェクトを保存できることを外部に意味します。

最初の質問から着想を得た基本的な例を使用するには：

const User = new Schema(
  {
    username: {
      type: String,
      index: true,
      unique: true
    },
    encryptedPassword: {
      type: String,
      required: true,
      minlength: 64,
      maxlength: 64
    }
})

User.virtual('password').set(function generate(inputWithCb, virtual, doc) {
  let cb = inputWithCb.cb;
  let password = inputWithCb.password;
  encryptor.hash(password)
  .then((hash) => {
    doc.set("encryptedPassword", hash);
    cb && cb();
  });
})

// create the document
const admin = new User({
  username: 'admin'
});
// setup the promise for setting the async virtuals
const pwdProm = new Promise((resolve) => {
  admin.set("password", {cb: resolve, password: "admin"});
})

//run the promise and save only when the virtual setters have finished executing
pwdProm
.then(() => {
  admin.save();
});

これは望ましくない結果をもたらす可能性があるため、自己責任で使用してください。

@siltopromiseを返すスキーマメソッドを使用してみませんか？

@ vkarpov15通常はこれを行いますが、これを行ったプロジェクトでは、json「プラン」から自動的に生成されたスキーマ、仮想、graphQLエンドポイントがあるため、特定の場合のメソッドではなく、統一された仮想インターフェイスを使用することをお勧めします。

@siltoコードサンプルを提供できますか？ これがどのように見えるか見てみたいです

セッターの場合は、保存するか、ドキュメントデータを探すだけでよい場合があります。保存する場合は、promiseであるため、promiseであるフィールドを確認し、解決してから保存できます。

データを検索する場合は、このモデルがPromiseタイプになることをスキーマオプションで定義するか、モデルを作成するときにスキーマをチェックし、promiseであるセッター、ゲッター、または仮想があるかどうかをチェックしてから、ターンします。それを約束に。

または、すでに持っているexecのような関数（execPopulate）を使用することもできます。

履歴書では、セッター、ゲッター、または仮想を持つデータを観察したい場合は、その問題に対応する関数を作成できます。データを保存したい場合は、同じ関数を使用してデータを変換できることはすでに約束されています。保存する前に。

以前はpromiseで仮想を使用していましたが、express-promiseを使用しているため、ほとんどの場合、promiseは気にしませんが、場合によってはDocを使用します。.then（）、私はその問題がないことを約束してセッターを使用したことがないので...

いずれにせよ、すべてのデータをすでに解決し、約束されたセッターを定義した後のすべての約束された仮想およびゲッターで「then」を使用する必要がない、ある種のラッパーがあると便利です。

私はあなたがこのアプローチであなたを助けることができることを望みます。

よろしくお願いします。

PS：約束された仮想の使用の典型的な例。私の場合、2つのパスを使用して、ドキュメントを削除できるかどうか、または外部データに従って更新できるかどうかを確認します。したがって、通常、他のモデルにクエリを実行して、このモデルを削除または変更できるかどうかを確認する必要があります。 。 前にも言ったように、express-promiseはこの問題を解決しますが、これらのタスクを実行できるかどうかを内部で確認したい場合は、以前にこのpromiseを解決する必要がありました。

@chumagerいくつかのコードサンプルを提供していただけますか？

こんにちは、たとえば、以下の私のコメントによると、私は2つの仮想_updateと_deleteと、スキーマで定義されていない場合にそれらの仮想を定義するプラグインを使用して、trueを返します。

クレジットを定義するためのシミュレーションモデルと、mktデータを使用してシミュレーションを公開するためのプロジェクトモードがあります。
シミュレーションに関連付けられているプロジェクトがある場合、シミュレーションを削除することはできません。また、プロジェクトが投資用に公開されている場合、シミュレーションを更新することはできません。

シミュレーションでのvirtual_updateの解決は、シミュレーションが参照され、ステータスが「En Financiamiento」のプロジェクトを検索することです。このクエリがtrueの場合、シミュレーションは更新できません...明らかに「find」は約束するので、仮想それも...

通常、フロントエンドでこの仮想を使用するので、データはオブジェクトを解決するモジュールによって解析されます（coまたはexpress-promiseは、結果の1つまたは配列に依存します）。

ドキュメントを見たい場合は、仮想がpromiseであることがわかるので、coモジュールを使用して解決する必要がありますが、すでにresultをpromiseとして使用する必要がありました...おそらく結果にcoを追加するだけです魔法をかけるか、検索後にcoを使用するプラグインを使用します...しかし、より自然に、結果セットはすでに仕事をしているようです。

私はマングースからデータを取得するために多くのエンドポイントを使用します。その関数をどこでも使用するか、検索にポストフックを使用する必要があります。

ゲッターでも同じことですが、セッターではフックを事前検証する必要がありますが、循環参照やコンストラクターなどの他の小道具があるため、ドキュメントの他の小道具に触れないことが重要です。

よろしく...

PS：本当にサンプルコードが必要な場合は、私に知らせてください。

@chumager散文の大きな壁！==コードサンプル。 私は本当にコードサンプルを好みます。