問題タブ [doctrine-mongodb]

For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.

0 投票する
2 に答える
480 参照

php - Zend Framework 2 Doctrine MongoDB ODM と Apache が遅すぎる

次の実行時に奇妙なパフォーマンスの問題が発生しています:

これが DB の問題ではないことは確かです(実際の MongoDB インスタンスで試してみましたが、結果は同じでした)。


シナリオ

以下のような方法で Doctrine ODM で動作するオブジェクトを定義しました。

これらを使用して約をインポートしています。製品データベースに 100 個の製品。これには実機で約5秒かかりますが、仮想マシンで試すと、約2秒かかります。同じことをするのに25秒。

問題は、これがすべて処理されている間に99% の負荷がかかっているApacheにあるように見えますが、実際に何が起こっているのかを特定するのは困難です。

どんな種類のアドバイスもいただければ幸いです...


アップデート

これは、データの書き込み時にのみ発生するようです。データの読み込みは問題ないようです。

Webgrind データ (スクリーンショット) が利用可能: https://www.dropbox.com/s/jjlg7ano6epy6t1/webgrind.png?dl=0

0 投票する
1 に答える
1966 参照

php - カスタム ユーザー プロバイダーを Silex で動作させるにはどうすればよいですか?

私は本当に2番目の目を使うことができました。Silex のSecurityServiceProviderを Doctrine MongoDB ODM と組み合わせて使用​​してカスタム ユーザー プロバイダーを作成しようとしていますが、ログインしようとすると次のエラーが表示され続けます。

注:ユーザーをハードコーディングすると、完全に機能します

私が知る限り、ここにある Silex のドキュメントに従っています。データベースからユーザーを正常に取得していることを確認したので、それが問題ではないことがわかりました。以下は、app.php からのスニペット、ユーザー クラス、およびカスタム ユーザー プロバイダー クラスを含む、関連するコードです。



0 投票する
1 に答える
789 参照

php - ドキュメントに子があるかどうかを効率的にチェックする

Doctrine MongoDB を使用して遅延読み込みツリーを構築しようとしています。私の文書は次のように構成されています。

次のコードは、特定のページのすべての子を取得します。

これは期待どおりに機能していますが、子ページごとに個別のクエリを実行して、それがリーフであるかどうかを確認します。多くの子ノードを持つ大きなツリーを扱う場合、効率的ではありません。

ページ ドキュメントにブール値を導入し、isLeaf永続化するときにそれを更新できます。ただし、これは、子を追加または削除するときに親を更新する必要があることも意味します。

この問題を解決するための指針はありますか?

0 投票する
2 に答える
1065 参照

php - Symfony2 MongoDB 複数接続エラー

Symfony2 で MongoDB をセットアップする際に問題があります。

仕様:

MongoDB の 2 つの異なるバンドル nxtlog と nxtsurvey で使用される 2 つのデータベースがあります。私が抱えていた最初の問題は、オプションに追加したデータベース名が考慮されていなかったため、データベースの「デフォルト」が使用され、もちろん存在しませんでした。また、両方の接続が非コア バンドルで使用されるため、default_connection と default_manager、さらには default_database も追加したくありません。

==== 試行 #1 ====

これが私が持っていた元の設定です:

機能させるために、各ドキュメント注釈にデータベースの名前を追加しました。

これは一時的な解決策ですが、私の計画は他のプロジェクトでバンドルを再利用することであるため、すべてのドキュメントを調べてデータベースの名前を設定する必要はありません。

==== 試行 #2 ====

私の2番目の試みは、ドキュメントに厳密に従うことでした。そのため、次のことを試しました。

次のエラーが表示されます。

そのため、接続とデータマネージャーに異なる名前を付けることはできないことがわかりました。私はそれを信じていなかったので、私はそれをグーグルで検索しました.誰かが同様の問題を抱えていました.答えはdoctrine_mongodbの下に以下を追加することでした:

しかし、この解決策は私にはうまくいきませんでした。さらにグーグルで調べたところ、バンドル (またはその一部) を作成した jmikola が間違いを犯したことがわかりました。彼はそれを修正したと言い、default_commit_options は必要な構成オプション。(参照https://github.com/doctrine/DoctrineMongoDBBundle/issues/222 )

この時点で、解決に時間がかかりすぎるため、助けが必要です。

ありがとう

0 投票する
2 に答える
646 参照

mongodb - DoctrineMongoDBBundle: Document Manager への読み取り設定の指定

読み取り専用に構成されたリモート データベースに接続しています。私が使用する場合:

うまくいきますが、試してみると:

次のエラーが表示されます。

マスターおよびスレーブではありませんOk=false

MongoClient の場合と同じように、$dm に読み取り設定を指定するにはどうすればよいですか?

前もって感謝します...

0 投票する
0 に答える
94 参照

php - DoctrineMongoDB で埋め込みドキュメントを永続化する際のエラー: 指定された配列

Doctrine-MongoDB と Symfony を使用するプロジェクトに取り組んでいます。

\@EmbedMany注釈を使用してドキュメントを別のドキュメントに埋め込みました。

ドキュメントは次のとおりです。

MusicalInfos :

そして埋め込まれたドキュメント:

その後、これらのドキュメントに記入するフォームを作成しました:

コントローラ

しかし、これを試みると、常にこの例外 が発生します。

どうしてか分かりません ...

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

0 投票する
0 に答える
674 参照

mongodb - Doctrine MongoDB ODM で非正規化されたデータ同期を適切に処理する方法

MongoDB を使用する場合、参照データの非正規化はかなり一般的な方法のようです。それでも、Doctrine MongoDB ODM でそれを処理する組み込みの方法は見当たりません。

ユーザーが相互にフォローできるソーシャル ネットワークがあるとします。ここに 2 つのユーザーの例を示します。

ご覧のとおり、「name」プロパティを非正規化する必要があります。私が言ったように、Doctrine ODM にはそれを行う組み込みの方法はないようです。この件に関する最新号は1 年前のものなので、自分でやろうと思います。

非正規化がどのような場合に役立つかを説明し、非正規化されたデータの一貫性を維持するのがいかに面倒であるかについて言及している記事をインターネット上でたくさん見つけましたが、正規化されていないデータの更新プロセスを実装する方法を説明する記事は見つかりませんでした。

私の場合、最終的に一貫性のあるデータで十分です。ユーザー名の更新と非正規化されたデータの更新の間に数時間かかることがあります。私はそれを行う3つの異なる方法を見ることができます:

1 - 整合性チェッカー: 非正規化データを定期的に更新するタスクをバックグラウンドで実行します。

2 - トリガーの更新: 名前フィールドを更新するたびに、関連するすべての非正規化データが 1 回のフラッシュで更新されます。

3 - ハイブリッド ソリューション 各ユーザーについて、名前が更新されると、更新情報と共にエントリがキューに追加され (ユーザーの更新とキューへの挿入は 1 回のフラッシュで行われます)、タスクが実行されます。バックグラウンドで実際の更新を行います。

最初の解決策は実装が最も簡単に思えますが、リソースを大量に消費する可能性があります。2 番目の解決策では、読み取り/書き込み比率が高くても、更新要求が途方もなく長くなり、これが問題になる可能性があります。3番目の解決策が進むべき道だと思いますが、そう考えるのは正しいですか?

また、データが非正規化されている各ドキュメントの preUpdate コールバックで同じコードを書き直す必要がないようにするなど、DRY の方法でそれを行いたいと考えています。カスタム注釈を作成することを考えていますが、それは良い考えですか?