問題タブ [natural-key]
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.
django - 別の自然キーを含む自然キーのDjango逆シリアル化
プレーヤーの統計を記録するモデルを作成しています。
最初に手動でデータポイントを入力することで、Djangoに自然キーを使用してデータをjsonファイルにシリアル化させることができますdumpdata --natural。私の計画は、このシリアル化された形式をコピーして、他のデータポイントを一括挿入することです。問題は、Djangoがを使用してjsonをデータベースに逆シリアル化しないことloaddataです。スローされるエラーは
DeserializationError:int()引数は、「リスト」ではなく、文字列または数値である必要があります
不平を言うjsonデータを少し簡略化しましたが、次のようになります。
{"pk": 1, "model": "nba.metric", "fields": {"player": ["Kobe Bryant", ["Lakers", 2012]]}}
私のモデルはそのようなものです:
どんな入力でも大歓迎です、ありがとう!
django - モデル マネージャはモデルのメタ属性 (`Meta.unique_together`) にアクセスできますか?
これは、一般化された自然キー モデル マネージャーに対する私の試みです。Meta.unique_together 属性から自然なキー フィールド名を決定しようとする (失敗する) ことを除いて、ドキュメントに似ています。
次のように for ループの直前にデバッグ プリントを挿入すると:
unqiue_together 属性はまったくリストされていません。
'abstract' は少し気になりましたが、別のデバッグ プリントは、私が自然キーで管理しようとしているモデルが抽象的ではないことを示しています。
多くの抽象基本クラスを混在させています。それが問題でしょうか?
完全を期すために、ミックスインの 1 つを次に示します。
ハードコーディングされたモデル マネージャーは問題なく動作します。
django - django外部キーのシリアル化で自然キーを使用できません
つまり、外部キーを持つクラスがあります。
これは私のコードです
さて、いつものように
json 出力には、必要な名前ではなく、ポップの「id」が含まれています。
だから私は Manager クラスを使用しました。これが今の私の Pop クラスです。
しかし、この後、私がするとき
TypeError: Equipment: eq1 is not JSON serializable というエラーが表示されます
この外部キーのシリアル化にも wadofstuff を試してみましたが、どうやら Django1.5 では simplejson と json の間に衝突があり、クエリがエラーをスローしていました。だから私は振り出しに戻ります。
どんな助けでも非常に高く評価されます。私は何時間も髪を分けています。
django - Djangoフィクスチャの主キーエラー、自然キーソリューションが必要
だから私は、多対多フィールドでActorsモデルのリストを保持するFilmモデルを持っています:
JSON フィクスチャからいくつかの初期データをロードしようとしていますが、問題は多対多のアクター フィールドをロードすることです。たとえば、次のエラーが表示されます。
DeserializationError: [u"'Anna-Varney' 値は整数でなければなりません。"]
これらのフィクスチャで:
私のアクターのフィクスチャは次のようになります。
したがって、多対多のフィールドは pk 整数を使用する必要がありますが、問題はデータがソートされていないことであり、アクターの長いリストの場合、それぞれの pk を手動で検索するのは実用的ではないと思います。私は解決策を探していましたが、自然キーを使用する必要があるようですが、モデルにそれらを適用する方法が正確にはわかりません。
編集:私は自分のモデルを次のように変更しました:
しかし、私はまだ同じエラーが発生しています
python - Get_by_natural_key が AttributeError をスローしますか?
Django のget_by_natural_key()メソッドの使用に問題があります。(ジャンゴ1.6)
次のようなコード番号を使用するアイテムがあります: ABC_1234。
マネージャーとモデル:
私のテストでは、このクエリがあります...
...このエラーがスローされます:
これを、関連するモデル フィクスチャの自然キーとして使用したいと思いcode_numberます。また、このモデルをクエリする汎用手段としても使用したいと思います。
私は何を間違っていますか?助言がありますか?
python - Djangoの自然キーがフィクスチャで機能しませんか?
Django のフィクスチャ/自然キーに問題があります。この回答で指定されているような、通常の問題のほとんどに対処したと思います。
get_by_natural_key はシェルで問題なく機能するため、これはすべて厄介な問題である可能性があります。
フィクスチャで何が間違っていますか?
ジャンゴ1.6
models.py
私の備品: pictures.yaml
エラー
したがって、 を実行する./manage.py loaddata picturesと、次のようになります。
python - get_by_natural_key と natural_key の違い
私が理解しているように、モデルマネージャーの get_by_natural_key はデシリアライズに使用され、natural_key はシリアライズに使用されます。これは本当ですか ?そうでない場合、違いは何ですか?
また、 --natural-foreign および --natural-primary キーを常に指定する必要がありますか? 自然キーを介してシリアライズ/デシリアライズを強制する方法はありますか?
hibernate-entitymanager - @NaturalId はルートエンティティ (またはその @MappedSuperclasses) でのみ有効で、結合された複数のテーブル継承で Natural Id を使用します
基本的に、ルート例外「@NaturalId only valid on root entity (またはその @MappedSuperclasses)」を検索タブに貼り付けるだけで、Googleで同様の問題を見つけることができません。結合された複数テーブルの継承戦略を使用して、抽象的な親( Person )を含む具象/子エンティティ( Student、Employee ) をデータベース内の 3 つのテーブルにマップしていますが、これまでのところ問題はありませんでした。 Student のStudentIdを使用して、私の Student Entity のカスタム クエリを実装する必要があります。. 基になる Hibernate-session を Entity-manager から抽出することに成功し、最愛の HibernateSession から必要なメソッドを明確に確認して使用できるようになりました (Hibernate には (byId、byNaturalId などの) naturalIds のメソッドがあることは誰もが知っています)。 )、これらの種類のメソッドは、エンティティのクエリに非常に役立ちます。そのため、studentId データ メンバーに@NaturalIdでアノテーションを付けるまで..何らかの操作 (保存/作成) を実行すると、複数行の例外がスローされます。そして根本的な原因は..
追加情報としてエンティティのコードを貼り付けます
Parent抽象基本クラス
人物クラス
Entityサブクラス
学生クラス
質問: さまざまな学生エンティティに対して一意のクエリを作成するためにできることはありますか? Hibernate の naturalId メソッドは、get や update などのエンティティを操作するのに非常に便利だからです。
エンティティとデータベース テーブルを使用して設計を犠牲にすることなく、目的を達成するための回避策はありますか? 可能であれば、studentId を naturalId として機能させたいと考えています。提案/ヘルプ/コメントをお願いします。どんなことでも大歓迎です。
mysql - MySQL テーブルに数値以外の主キーを使用できますか?
私の Web アプリケーションでは、ユーザーはドキュメントを定義し、そのドキュメントを識別する一意の名前と、人間がドキュメントを参照するために使用するわかりやすい名前をドキュメントに付けることができます。例として、次のテーブル スキーマを取り上げます。
この例idでは、自動インクリメント番号である主キーとして列を使用しました。ドキュメント ( ) の自然な ID が既にあるので、次のnameようにすることもできます。
この例でnameは、ドキュメントの主キーです。テーブル内のすべてのドキュメントはとにかく一意である必要があるためid、基本的に の複製であるため、フィールドを削除しました。namename
これはまた、外部キー関係からドキュメントを参照するときに、.document_nameではなくそれを呼び出さなければならないことを意味しdocument_idます。
これに関するベストプラクティスは何ですか? 理論的にVARCHARは、主キーに a を使用することは完全に可能ですが、パフォーマンスのオーバーヘッドなどの欠点はありますか?