問題タブ [doctrine-orm]

ネイティブWebProfileBundleで機能するには、SQLログを追加する必要があります。アプリケーション構成でデフォルトの接続を1つ実行すると、ログにSQLクエリが表示されます。しかし、私のアプリケーションは多くのdbサーバーへの多くの接続を使用しているため、構成ファイルにすべての可能な接続を追加することはできません。

ランタイム接続を作成します。つまり、次のようになります。

それなら私は、このようなコマンドを実行する必要があると思います

DependencyInjectionを使用してこの問題を解決しようとしましたが、DoctrineBundleを例として取り上げました。しかし、運がありません。

ライブコードや適切なドキュメントへのリンクに関するヘルプは素晴らしいでしょう

私はこのDoctrineクエリを受け取りました：

ただし、次のメッセージで例外がスローされます。

group byとを省略すればorder by動作します。

この場合、ネイティブクエリを使用する必要がありますか、それともクライアントコードで並べ替えとグループ化を行う必要がありますか（データベース内のデータの量によっては、おそらくあまり良い考えではありません...）、またはこのクエリを機能させることは可能ですか？ ？

ありがとう！

編集：

これは私の現在のアプローチであり、それほど良いものではありませんが、データベースに多くのデータがないため、現時点では機能します。

認識されないフィールドを与える：所有者

もちろん回避策はありますが、見た目は醜いです

独自のメソッドを記述せずにfindByを使用する可能性はありますか？

既存のデータベース スキーマから、関連する docblock 注釈を使用して Doctrine 2 エンティティを生成することは可能ですか?

さまざまな装飾（または印刷）オプションを持つことができる製品を備えたシステムがあるとします。

ほとんどの製品には同様の範囲の印刷オプション名がありますが、単一の製品に固有の製品もあります。

たとえば、3つの異なる装飾オプションを持つことができるキャップを持つことができます：

1. ブランドなし
2. ワンカラープリント
3. 刺繍

私の目標は、管理者ユーザーが作成する装飾オプション名を最小限に抑えて、常に同じになるようにすることです。IE「1カラープリント」と呼ばれる装飾オプションと「1カラープリント」と呼ばれる別の装飾オプションは必要ありません。

したがって、私の計画はUIにあり、既存の装飾オプション名をドロップダウンするだけでなく、新しい装飾オプション名を追加するオプションも提供します（エッジケースの場合）。

ただし、各装飾オプションには、セットアップコスト、製造時間など、製品によって異なるさまざまなデータが含まれています。

たとえば、Hat1とHat2の両方に刺繡装飾オプションを設定できますが、Hat1のセットアップコストは49ドルで、Hat2のセットアップコストはわずか35ドルです。

だから私の質問は、私のエンティティを構造化するための最良の方法は何ですか？Product、DecorationOption、DecorationOptionNameの3つのエンティティが必要ですか？または、ProductとDecorationOptionの2つのエンティティだけですか？

さらに理解するには、私のコード例を参照してください。

1. 3つのエンティティオプション
2. 2つのエンティティオプション

e コマース アプリケーション用のデータベース/ドメインを設計していますが、製品を保存する方法を理解するのに苦労しています。

このウェブサイトでは、ペン、皮ひも、タトゥー、傘など、あらゆる商品を幅広く販売します。これらの各製品には、高さ、幅、長さ、重量などのいくつかの共通の属性がありますが、一部の製品には特別なデータがあります。たとえば、ペンにはさまざまなインクの色があり、ペン先/ふたやパンフレットにはさまざまな種類の折り目があります。これまでに 20 以上の追加の属性を考えましたが、これらの属性は Web サイト上の製品の 1% にしか適用されない場合があります。

そのため、余分なデータを処理するために EAV モデルを実装することが適切かどうか疑問に思っています。顧客がフロントエンドでサイトを閲覧している場合、eBay や carsales.com.au のようなフィルタリング サイドバーが表示されることに注意してください。（そのため、かなりのクエリが発生することに注意してください）

システムの柔軟性を維持する必要があるため、クラス テーブルの継承を実装するのは実用的ではないと思います。これは、今後、新しいタイプの製品でより多くの属性が追加される可能性があるためです。

私が検討したもう 1 つのことは、NoSQL データベース (おそらく MongoDB) を使用することですが、これらのタイプのデータベースの経験はほとんどありません。問題は解決しますか?

オプションのレビュー:

1. 多くの列を持つ単一の製品エンティティ
2. 個別属性エンティティ (EAV)
3. スキーマレス永続性に切り替える

私は、属性エンティティを使用してプロトタイプを作成し、それがどれほど柔軟であるかを確認し、パフォーマンスとクエリがどのように制御不能になるかをテストしています。

編集：もちろん、私は他の解決策を受け入れます。

私は小さなプロジェクト（教科のいくつかのマーク追跡ソフトウェア-sqlite DBを備えたPHPフロントエンド）に取り組んでおり、ORMを使用することにしました。

RedBeanPHPを調べましたが、少し制限がありすぎて好みに合わないようでした。そのため、私はDoctrineを試してみることにしました。

ORMに関する私の唯一の以前の経験は、.NETでのLINQtoSQLです。とにかく、私はDoctrine 2.0（現在ベータ版です）を使い始めるべきか、それとも1.2を学ぶために少し時間がかかるべきかどうか疑問に思っていました。

両方に満足している人からのフィードバックを探しています。さらに重要なことに、Doctrine2.0のドキュメントがどれほど完全であるかを知りたいと思います。Doctrineを初めて使用する（そしてORMをまったく使用しない）人が2.0を起動して実行するのに十分な情報がウェブサイトにありますか、それとも新しいバージョンのドキュメントがまだかなり不足していますか？

スカラー水和を使用するときに教義がエンティティ フィールド名に追加するエンティティの dql エイリアスを取得する方法はありますか?

を実行するdoctrine orm:validate-schemaと、マップされた列がパブリックであり、getter/setter メソッドを使用してそれらをラップしていないという警告が多数表示されます。「遅延読み込みを中断する」と書かれています。関連付けられたコレクションをパブリックにすることが問題になる可能性があることは理解できますが (私はこれらをプライベートにしてラップしています)、オブジェクトのフィールドではどのように問題になるのでしょうか? 私の知る限り、フィールドは完全にロードされています。

奇妙な問題があります。Doctrine 2 でプロキシの自動生成をオフにしたいです。このトリックを実行する必要がある (そして実行する) 次のコード行を見つけました。

私のテスト環境では、プロキシはapplication/proxiesにあります。すなわち:

私がライブ環境にいるとき、私のコードは突然、実際の場所ではないapplication/proxies/Proxiesでプロキシを検索します。

名前空間と関係があることは理解していますが、 setAutoGenerateProxyメソッドを使用すると動作が異なる理由がわかりません。

何か案は？

編集

以下を使用して新しいプロキシを生成しました。

オプション。

これにより、次の出力が得られました。

最後の行を見ると、プロキシは /var/www/application/proxies に生成されています。ディレクトリのリストは次のようになります。

したがって、余分な Proxies ディレクトリはありません。しかし、ウェブページを更新すると、あると思われるため、次のエラーが表示されます。

Proxies ディレクトリが追加されるのはなぜですか? リクエストごとにプロキシを生成すると、余分な Proxies ディレクトリは検索されません。誰か？

@Bryan M.:これは解決策ではなく、回避策です。その上、それは機能しません。プロキシを生成するときに、提案を適用すると、APPPATHSYSTEM で生成され、私の webapp は APPPATHSYSTEM."Proxies" からそれらをロードしようとします。問題は、次を使用すると、システムが別の場所でプロキシを検索することです。

DEVELOPMENT が true の場合、APPPATHSYSTEM が参照されます。DEVELOPMENT が false に設定されている場合、APPPATHSYSTEM."Proxies" が参照されます。DEVELOPMENT コンスタンスを切り替えるだけでアプリケーションが壊れます。理論的には不可能です。