問題タブ [petapoco]

ID、Name、CustomerIDの定義を持つUserクラスと、ID、Name、Addressの定義を持つCustomerクラスがあります。

次のクエリを試していますが、キーワード「user」の近くに構文が正しくないというエラーメッセージが表示されます。

SQLの何が問題になっていますか？

私はSQLを書き込もうとしています

次のことを達成するために、式ツリーと匿名型を使用しようとしています。

このクラスがあるとしましょう：

今、私は以下を呼び出すことができるようにしたい:

名前に「LastName」と「DateOfBirth」の 2 つの項目を含めたい。

すべてを選択するのではなく、SQL に含めたいプロパティ/列のリストを指定できるように、文字列 sql を記述するのではなく、コンパイル時に安全な方法でPetaPocoを拡張しようとしています。非常に大きなエンティティがいくつかあり、パフォーマンス上の理由からすべての列を選択したくない場合があります。

AppHarbor で実行されている Asp.net MVC アプリケーションがあります。毎日の電子メール注文プロセスがあります。

1. ユーザーは電子メールを入力して送信します。
2. システムが注文を処理し、リンクが記載された電子メールを送信します。
3. ユーザーは電子メールを確認し、リンクをクリックして次のステップを実行します...

問題は、ステップ 2 と 3 の間で多くの時間が経過する可能性があることです。メールをすぐにチェックするユーザーもいれば、1 日後またはそれ以降にチェックするユーザーもいます。主なことは、サーバー上のアプリケーションが終了するのに十分な時間が経過することです。

したがって、ユーザーがリンクをクリックすると、アプリケーションがバックアップを開始するまで少し待たなければならないことを意味する場合があります...

質問

ステップ #3 がデータベース内のレコードを処理すると、datetimeステップ #3 が行われたときのタイムスタンプ (タイプはもちろん) で更新されます。しかし、これを理解してください：完全に同一のタイムスタンプを持つレコードを見ることができます！どうすればそれが起こりますか？

タイムスタンプはアプリケーション層で生成され、更新されたものをデータベースにプッシュします。データアクセスには PetaPoco を使用しています。

複数のレコードが同時に記録される原因は何ですか? 私のアプリケーションはトラフィックが非常に少ないため、実際には日中にシャットダウンすることがあるため、複数 (最大 3 人) のユーザーがまったく同時にステップ 3 を実行したとは信じがたいです。そして、これは単一のプロセスで実行されているため、不可能だと思います...

これの原因は何ですか？

更新コードは本当に簡単です

ResultColumn属性が設定された POCO クラスがあり、Single<Entity>()呼び出しを行うと、結果列がマップされません。その値は常にSQL 列のデフォルトの制約によって生成される必要があるため、列を結果列に設定しました。この列がビジネス レイヤーから挿入または更新されることは望ましくありません。私が言おうとしているのは、私の列の型は単純な SQL データ型であり、関連するエンティティ型ではないということです (ResultColumn主にそれらで使用されているように)。

コードを見ると、PetaPoco に次の行が表示されます。

結果列が自動選択ステートメントから除外されるのはなぜですか。私が理解しているように、その性質は読み取り専用であるためです。そのため、 selects のみで使用されます。このシナリオは、列が実際に関連エンティティ タイプ (複合型) である場合に見られます。Ok。しかし、そのような別の属性が必要であり、そのような属性ComputedColumnAttributeは常に選択で返されますが、挿入や更新では使用されません...

では、PetaPoco チームが select から結果列を省略することにしたのはなぜですか?
それでは、結果列をどのように読むべきですか?

ODBC を使用して Navision 2.60 に接続しようとしています。odbc 接続を管理するための静的クラスがあります。

Petapoco や Dapper などのエンティティのマッピングに ORM を使用したいのですが、その例はありますか?

私は Web ベースのペニー オークション ポータルに取り組んでいます。Asp.net MVC 3 アーキテクチャのデータ アクセス クラス ライブラリとして PetaPoco を使用しています。ストアド プロシージャを使用したマルチテーブル データ プルの問題に直面しています。フロントエンドで必要なストアド プロシージャ フィールドをマッピングするためのビュー モデル POCO を作成しました。

モデルを見る:

コントローラ

必要なもの

複数の結合を使用してデータベースからデータを取得し、ストアド プロシージャを使用して (ビュー モデル クラスを使用して) ビューに表示する必要があります。

私はクエリを持っています

エラーメッセージが表示されます：

マルチパート識別子「Condition.ID」をバインドできませんでした。FROM 句のオブジェクト "Issue" と "Issue" は、公開されている同じ名前を持っています。相関名を使用してそれらを区別します。

上記で何を着用していますか？

petapoco と mvc3 で効率的なページングを行う方法はありますか。現在、私はすべてのレコードを取得していますが、これは完全な方法ではありません。

LINQ skip() take() を使えばとても簡単でした。

注: これはオークション ポータルに実装される予定であり、データベースは膨大になります。

専門家は、いくつかの光を当ててください。

私は PetaPOCO と Dapper を使い始めましたが、どちらにも独自の制限があります。しかし逆に、それらは Entity Framework よりも非常に高速であるため、その制限を手放す傾向があります。

私の質問は、1 対多、多対 1、多対多の関係を具体的に定義できる ORM はありますか? Dapper.Net と PetaPOCO はどちらも、これらの関係を偽造するハック的な方法を実装しています。それを処理できる単一のマイクロ ORM がない場合、私の 2 番目の質問は、これらのマイクロ ORM は関係を定義するのにそれほど適していないという事実を手放し、すべてのタイプに対して新しい POCO エンティティを作成する必要があるかどうかです。これらのタイプのマルチ結合を含む、実行するクエリの これはうまくスケーリングできますか？

私の質問が明確であることを願っています。そうでない場合は、お知らせください。

現在のアプリケーションでは、データベースの操作にスマートオブジェクトスタイルを使用しています。代わりに、PetaPocoへの移行の実現可能性を検討しています。機能を確認すると、属性を追加してオブジェクトをCRUDしやすくすることができます。これらの属性を追加すると、注意すべきマイナスの副作用がありますか？

これらのデコレータを使用しない理由を見つけた人はいますか？