6

Meteor 4.2（Windows）を使用していますが、コレクション内のオブジェクトを更新しようとすると、常に「更新に失敗しました：403-アクセスが拒否されました。制限付きコレクション内のドキュメントを置き換えられません」というメッセージが表示されます。不思議なことに、新しいものを挿入するのに問題はなく、更新だけが失敗しています。

コレクションのすべてを「許可」しようとしました。

Maps.allow({
    insert: function () { return true; },
    update: function () { return true; },
    remove: function () { return true; },
    fetch: function () { return true; }
});

しかし、それでも、この更新は失敗します。

Maps.update({ 
    _id: Session.get('current_map') 
}, {
    name: $('#newMapName').val()
});

他に確認できることはありますか？それとも私のコードが間違っていますか？前回プロジェクトで遊んだのは、以前のバージョンのMeteor（<4.0）でした。

ご協力いただきありがとうございます。

PS：ちなみに、この更新を行うと、ローカルコレクションが更新され、UIで変更を確認できます。その後、変更がサーバー側で拒否されたため、エラーメッセージとともにすぐに元に戻されます。

4

2 に答える 2

8

了解しました。構文は実際には正しくありませんでした。以前はうまく機能していたので、理由はよくわかりませんが、とにかく、正常に機能するコードは次のとおりです。

Maps.update({ 
    Session.get('current_map') 
}, {
    $set: { 
        name: $('#newMapName').val()
    }
});
于 2012-10-15T01:36:44.413 に答える
0

'current_map'セッション変数に格納しているものに関連している必要があるようです。それがdbオブジェクトの場合{_id:<mongo id here>}、更新ファインダーが正しく機能するように見える可能性があります。

私は同じ問題に遭遇し、次のことが機能することを発見しました

Blocks.update {_id:block_id}, {$set: params}

ここで、paramsは更新したいすべてのビットのハッシュであり、block_idは更新しようとしているブロックのmongoオブジェクトIDです。

クライアント側の更新（更新をフラッシュしてから元に戻す）に関するメモは、予想される動作です。データとセキュリティのセクションでドキュメントを確認すると、次のようになります。

Meteorにはかわいいトリックがあります。クライアントがサーバーへの書き込みを発行すると、サーバーの応答を待たずに、ローカルキャッシュもすぐに更新されます。これは、画面がすぐに再描画されることを意味します。サーバーが更新を受け入れた場合（適切に動作しているクライアントでほとんどの場合に発生するはずです）、クライアントは変更にジャンプし、ラウンドトリップが自身の画面を更新するのを待つ必要はありませんでした。サーバーが変更を拒否した場合、Meteorはサーバーの結果でクライアントのキャッシュにパッチを適用します。

于 2013-02-05T16:35:45.890 に答える