これは、SQLAlchemy および sqlautocode の主キー制約に関連しています。SA 0.5.1 と sqlautocode 0.6b1 があります。主キーのない MySQL テーブルがあります。sqlautocode は、「主キー列をアセンブルできませんでした」というトレースバックを吐き出します。
主キーのないテーブルを反映するように、パッチでこれを修正できますか?
ありがとう、ヴィニート・デオダール
これは、SQLAlchemy および sqlautocode の主キー制約に関連しています。SA 0.5.1 と sqlautocode 0.6b1 があります。主キーのない MySQL テーブルがあります。sqlautocode は、「主キー列をアセンブルできませんでした」というトレースバックを吐き出します。
主キーのないテーブルを反映するように、パッチでこれを修正できますか?
ありがとう、ヴィニート・デオダール
私はそうは思わない。レコードを一意に識別する方法なしに、オブジェクトをデータベースに永続化するために ORM はどのように想定されていますか?
ただし、ほとんどの ORM は primary_key 引数を受け入れるため、キーがデータベースで明示的に定義されていない場合はキーを示すことができます。
基になるテーブルに一意に識別する列の組み合わせがある場合、sqa を偽装することに成功しました。
これがあなた自身のテーブルで、ライブではない場合は、主キーの整数列などを追加してください。
データベース内の既存のレガシー テーブルを、a) pk なし、b) 他の列の主キーのプロキシなしでマッピングすることさえできました。MySQL ではなく Oracle でしたが、sqa をハックして Oracle の行 ID を pk として表示することができましたが、これは挿入とクエリに対してのみ安全です...どの行を更新する必要があるかを一意に識別できないため、更新はできません。しかし、これらは醜いハックなので、できることなら、その道をたどらないでください。
テーブルの PK を決定できないために sqlautocode がクラス コードを生成しないという問題がある場合は、ニーズに合わせてそのコードを変更できる可能性があります (PK を持たない SQLA コードを生成することを意味する場合でも)。 )。最終的に、SQLA の ORM 側を使用している場合は、データベースが明示的にフィールドにラベルを付けていなくても、PK として定義されたフィールドが必要になります。