問題タブ [integrity]

データベースに新しい情報を挿入するとき、Doctrine 2 と OneToOne の関係に問題があります。

モデル: User.php

モデル: UserAuth.php

データを取得して更新するのに問題はありません:

ただし、新しいものを作成することはできません:

エラー:

Doctrine は、テーブル user_auth に新しいエントリを作成するための user_id を見つけられません。しかし、私は私のモデルで @JoinColumn(name="user_id", referencedColumnName="id") を示しました...あなたの助けのために! 私はこれを一日中探しました。

Magento でクレジット/デビット カードを使用して注文すると、次のエラーが表示されます。

それを見せたくなかったので、正確なトレースを取得できませんでしたが、app/code/core/Mage/Checkout/controllers/OnepageController.phpオンライン501（未編集）までトレースしました。正確な行は次のとおりです。

さて、ロジックは、注文を追加しようとすると、これは同じキーを持つ 2 つの注文であると教えてくれます。それとも完全に間違っているのでしょうか?

とにかく、これ以外で、これを修正する最良の方法は何ですか? 注文をエクスポートして、すべて削除してから再インポートすることを考えましたが、うまくいかない気がします。

私はMagento 1.6.2.0を使用しています

編集:整合性チェックに失敗しているテーブルを見つけた場合、そのテーブルを空にする可能性があることに気付きました(テーブルによっては)。これで自動的に修正されますか? どのテーブルが台無しになっているかを調べる方法についてのアイデアはありますか?

EDIT2：OğuzÇelikdemirの答えの後、次のことが原因であることがわかりました：

明らかに、同じ tax_id を 2 つ挿入することはできません。誰でもそれを修正する方法を知っていますか?

「yyyy-mm-dd hh:mm:ss」形式でのみ日付を挿入するようにユーザーに強制するにはどうすればよいですか。

「CONVERT」関数を使用して、いつでも任意の形式で日付を変換できることを理解しています。しかし、私はユーザーがこの形式で日付を入力するのが好きです。

また

データベースに入力された日付の形式が正しいかどうかを確認するにはどうすればよいですか。日付をチェックする関数を使用するのが好きです。

通信プロトコルが HTTPS の場合、ペイロードに何らかのチェックサムを追加すると効果がありますか? 正確には。

1. 整合性を確保するために、コンテンツ本体にチェックサムを設定することは適切ですか?
2. 整合性を確保するために、ファイル/マルチパート コンテンツのチェックサムを持つことは良いことですか?
3. 1も2もあると便利
4. どちらも必要ありません

私はWebサービスのみの観点からもっと考えています。

SHA3​​84は、SHA512の切り捨てられたバージョンです。しかし、なぜ誰かがそれを使うのでしょうか？そして当然の結果：SHA384がSHA512と同じくらい優れている場合、512ビットバージョンを使用する理由はありますか？

ファイルの整合性を検証するためにアルゴリズムの1つを使用することを計画しているので、主に衝突セキュリティに関心があります。

誰かが実際にSHA2ダイジェストをどのように使用しているか、そしてなぜ一方のバージョンを他方よりも選択したのかを聞いてうれしく思います。

現在、監視システム用の現在のメディア ストレージ (ビデオ/オーディオ/メタデータを保存するため) のアップグレードを開発しており、記録構造をより堅牢なソリューションに再設計しています。

データファイルに格納されているデータのインデックスデータを作成する必要があるため、インデックスファイル構造を作成していますが、ハードディスクの障害が心配です (インデックスファイルの書き込み中に電源が切られた場合を想像してください。データが半分書き込まれる可能性が高いため、破損します)。インデックスの保存方法は既に設計済みですが、電源障害やディスク障害によるデータの破損が懸念されます。

それで、書き込み時にデータの破損を避けるためのテクニックを知っている人はいますか?

私はすでに少し検索しましたが、良い解決策は見つかりませんでした.1つの解決策は、ファイルに書き込まれるすべてのログを作成することでしたが、1秒あたりのI/Oがさらに多くなります(I/ 1 秒あたりの Os も、システムのパフォーマンスを可能な限り低くする必要があります)。

私が思いついたのは、インデックス ファイル内の機密データを、タイムスタンプ フィールドとチェックサム フィールドと共に複製することでした。例えば：

Field1 Field2 Field3 タイムスタンプ チェックサム

Field1 Field2 Field3 タイムスタンプ チェックサム

したがって、ファイルを読み取るときに最初のフィールド セットが破損している場合 (チェックサムが一致しない)、データが 2 回書き込まれます。2 番目のフィールド セットは問題ありません。書き込みが途中で停止した場合、破損が発生すると考えられます。たとえば、ソフトウェアが最初のフィールドのセットを書き込んでいるときに電源障害が発生した場合、2 番目のセットはそのまま残ります... 2 番目のフィールドの電源障害が発生した場合セットが書き込まれていますが、最初のセットはすでに無傷です。

皆さんは、この解決策についてどう思いますか? データの破損を回避しますか?

ところで、トランザクション NTFS でシステムを展開するための制限により、この種のストレージまたはトランザクション NTFS にはどのような種類のデータベースも使用できません。

どんなアイデアでも大歓迎です、ありがとう！

属性の末尾に_idを追加することによって引き起こされる完全性エラーに関するいくつかの例を読みましたが、それらのほとんどは、私が持っているエラーではないuser_idを考慮しています-私のものは、外部キーの初期値を別の値に設定することですモデル (レシピにはクックブックへの fk があります)

ここに私の痕跡があります

ご覧のとおり、original_cookbook という名前のforeign_key があり、これをユーザーのクックブックに初期設定したいと考えています。

これを引き起こしている可能性のあるアイデアは、必要に応じてさらにコードを送信できます

ありがとう

スナックフィッシュ

もちろん、MD5 は CRC32 よりも優れており、SHA1 は MD5 よりも優れています。また、CRC32 よりもはるかに低速です。

転送されたファイルの一貫性をチェックする方法を考えており、CRC32 が最速のオプションです。

整合性チェックで CRC32 がどれほど悪いかはどこにもわかりませんでした(つまり、CRC32 が不正な形式のファイルを検出しないのはなぜでしょうか)。

ディーター ゴルマンのコンピューター セキュリティの本では、Biba モデルの下で、*-property は次のように説明されています。

サブジェクト s がオブジェクト o を読み取る (観察する) ことができる場合、s は、fo(p)<=fo(o) の場合にのみ、他のオブジェクト p への書き込みアクセスを持つことができます。

この声明の最終的な考え方は、単純に「読まない」またはそのようなものでなければならないことを期待しています（インターネットのリソースによると）。しかし、この声明がその考えをどのように表現しているか理解できません。誰か説明してくれませんか？

フォームを送信すると、IntegrityError (1048, "Column 'paid_on' cannot be null").

いくつかの調査の後null=True, blank=True、models.py のアイテムの定義に含めることで多くの人が同様の問題を解決していることを発見しましたが、これを「paid_on」モデルに追加しても問題は解決しませんでした。

これが私のmodels.pyのクラスです:

ご意見ありがとうございます。