リリースノート
0.20.1
✨ 大きな変化
- これはOrmarの最初の非ベータ版であり、Pydantic v 2をサポートしていることに注意してください。0.20.0のリリースノートとhttps://collerek.github.io/ormar/0.20.0b1/migration/を確認してください
🐛 修正する
- select_lateとprefetch_lateを使用して同じターゲットモデルをマージする問題を修正しました#906
- pkモデルのみに関連する保存の問題を修正#812
- 同じリレーションシップを複数回追加するとリレーションシップキャッシュが破損する問題を修正#1335
✨ 特徴
- @cmflynnを使用して外部キーインデックス#1276を追加できます
💬その他
- @Chaoyingzはいくつかの文書を修正しました、ありがとうございます!
0.20.0
✨ 大きな変化
-
オマモデル構成
ここで、すべてのormarモデルには、Metaクラスを定義するのではなく、OrmarConfigクラスのインスタンスであるormar_configパラメータが必要です。このプロパティは、ormar_configという名前で、configクラスのインスタンスである必要があることに注意してください。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29
データベースのインポート インポートまたは sqlalchemyをインポート データベース=データベース。データベース("sqlite:///db. sqlite") Metadata=sqlalchemy. MetaData() #ormar<0.20 class Album(ormar. Model): クラスMeta: データベース メタデータ tablename="アルバム" id: int=ormar.Integer(プライマリキー=True) name: str=ormar.String(max_length=100) お気に入り: bool=ormar.Boolean(default=False) #ormar>=0.20 class AlbumV 20(ormar. Model): ormar_config=ormar. OrmarConfig データベース=データベース、 metadata=メタデータ, tablename="アルバム_v 20" ) id: int=ormar.Integer(プライマリキー=True) name: str=ormar.String(max_length=100) お気に入り: bool=ormar.Boolean(default=False) -
OrmarConfig API/パラメータ
ormar_configはMetaクラスで提供されているものと同じ設定セットを公開します。これは、次のいずれかのパラメータを使用して設定を初期化できることを意味します。
1 2 3 4 5 6 7 8 9 10
メタデータ:オプション[sqlalchemy. MetaData] データベース:オプション[データベース.データベース] engine:オプション[sqlalchemy. engine.Engine] tablename:オプション[str] order_by:オプション[リスト[str]] アブストラクト: bool 除外_親フィールド:オプション[リスト[str]] queryset_class:タイプ[QuerySet] エクストラ:エクストラ 制約:オプション[リスト[ColumnCollectionConstraint]] -
BaseMeta同等物-ベストプラクティス
コードの重複を減らし、開発を簡素化するために、基本構成を作成し、モデルごとにコピーを提供することをお勧めします。OrmarConfigは、このための便利なコピー方法を提供します。
copyメソッドはOrmarConfig in itと同じ引数を受け付けるため、必要に応じて上書きできますが、デフォルトでは、tablename、order_by、およびデフォルトでクリアされる制約を除いて、既存のプロパティを返します。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24
データベースのインポート インポートまたは sqlalchemyをインポート base_ormar_config=ormar. OrmarConfig(ベースの設定 Database("sqlite:///db. sqlite"), Metadata=sqlalchemy. MetaData() ) class AlbumV 20(ormar. Model): base_ormer_config. copyを使用します。 tablename="アルバム_v 20" ) id: int=ormar.Integer(プライマリキー=True) name: str=ormar.String(max_length=100) class TrackV 20(ormar. Model): base_ormer_config. copyを使用します。 tablename="track_v 20" ) id: int=ormar.Integer(プライマリキー=True) name: str=ormar.String(max_length=100) -
optionsフィールドパラメータはサポートされなくなりました。
バージョン0.20以前は、任意の既存のormarフィールドにオプションパラメータを指定して、受け入れ可能な値を制限することができました。この機能は削除され、この目的のために設計されたormar. Enumフィールドを使用する必要があります。 データベースフィールドタイプ(つまり、整数セグメント)を保持する場合は、いつでもカスタムベリファイアを記述できます。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36
データベースのインポート インポートまたは sqlalchemyをインポート データベース=データベース。データベース("sqlite:///db. sqlite") Metadata=sqlalchemy. MetaData() #ormar<0.20 class Artist(ormar. Model): クラスMeta: データベース メタデータ id: int=ormar.Integer(プライマリキー=True) name: str=ormar.String(max_length=100) 国: str=ormar.String(デフォルト=False、max_length=50、選択肢=["UK","US","Vietnam","コロンビア"]) #ormar>=0.20 from enumインポートEnum class Country(str, Enum): UK="UK" US="US" ベトナム=「ベトナム」 コロンビア="コロンビア" class ArtistV 20(ormar. Model): ormar_config=ormar. OrmarConfig データベース=データベース、 metadata=メタデータ, tablename="artists_v 20" ) id: int=ormar.Integer(プライマリキー=True) name: str=ormar.String(max_length=100) Country: Country=ormar.Enum(enum_class=Country) -
pydantic_onlyはフィールドパラメータをサポートしなくなりました
pydantic_onlyフィールドは廃止され、v 0.20で削除されました。Ormarは通常のpydanticモデルと同様にpydanticフィールドを定義することができます。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29
データベースのインポート インポートまたは sqlalchemyをインポート データベース=データベース。データベース("sqlite:///db. sqlite") Metadata=sqlalchemy. MetaData() #ormar<0.20 class Dish(ormar. Model): クラスMeta: データベース メタデータ tablename="皿" id: int=ormar.Integer(プライマリキー=True) name: str=ormar.String(max_length=100) cook: str=ormar.String(max_length=40,pydantic_only=True,default="sam") #ormar>=0.20 class DishV 20(ormar. Model): ormar_config=ormar. OrmarConfig データベース=データベース、 metadata=メタデータ, tablename="dishes_v 20" ) id: int=ormar.Integer(プライマリキー=True) name: str=ormar.String(max_length=100) cook: str="sam"#これは通常のピダンティック場です -
プロパティ_fieldデコレータはサポートされなくなりました
property_fieldデコレータは、モデルのディクショナリ/シリアル化されたjson表現に含まれる計算フィールドを渡すメソッドを提供するために使用されます。pydanticバージョン2. Xではこの可能性が導入されていますので、ここでpydanticネイティブバージョンに切り替える必要があります。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36
データベースのインポート インポートまたは sqlalchemyをインポート pydanticをインポート データベース=データベース。データベース("sqlite:///db. sqlite") Metadata=sqlalchemy. MetaData() #ormar<0.20 class Employee(ormar. Model): クラスMeta: データベース メタデータ id: int=ormar.Integer(プライマリキー=True) first_name: str=ormar.String(max_length=100) last_name: str=ormar.String(max_length=100) @ormar. properties_field() def full_name(self)->str: return f"{self.first_name}{self.last_name}" #ormar>=0.20 class EmployeeV 20(ormar. Model): ormar_config=ormar. OrmarConfig データベース=データベース、 metadata=メタデータ, ) id: int=ormar.Integer(プライマリキー=True) first_name: str=ormar.String(max_length=100) last_name: str=ormar.String(max_length=100) @pydantic. computed_field() def full_name(self)->str: return f"{self.first_name}{self.last_name}" -
廃止されたメソッド
以下にリストされているすべてのメソッドは廃止され、ormar 0.30で削除されます。
-
dict()はmodel_dump()になります
データベースのインポート インポートまたは sqlalchemyをインポート
データベース=データベース。データベース("sqlite:///db. sqlite") Metadata=sqlalchemy. MetaData()
class Album(ormar. Model): ormar_config=ormar. OrmarConfig データベース=データベース、 metadata=メタデータ, tablename="アルバム" )
1 2 3
id: int=ormar.Integer(プライマリキー=True) name: str=ormar.String(max_length=100) お気に入り: bool=ormar.Boolean(default=False)アルバム名: Dark Side of the Moon
ormar<0.20
アルバム_dict=アルバム. dict()
ormar>=0.20
new_アルバム_dict=アルバム.モデルダンプ()
引数はそのまま、つまりインクルード、除外などであることに注意してください。
-
json()はmodel_dump_json()になります
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25
データベースのインポート インポートまたは sqlalchemyをインポート データベース=データベース。データベース("sqlite:///db. sqlite") Metadata=sqlalchemy. MetaData() class Album(ormar. Model): ormar_config=ormar. OrmarConfig データベース=データベース、 metadata=メタデータ, tablename="アルバム" ) id: int=ormar.Integer(プライマリキー=True) name: str=ormar.String(max_length=100) お気に入り: bool=ormar.Boolean(default=False) アルバム名: Dark Side of the Moon #ormar<0.20 アルバム_json=アルバム. json() #ormar>=0.20 new_アルバム_dict=アルバム. model_dump_json()引数はそのまま、つまりインクルード、除外などであることに注意してください。
-
構築()をmodel_構築()に変更する
データベースのインポート インポートまたは sqlalchemyをインポート
データベース=データベース。データベース("sqlite:///db. sqlite") Metadata=sqlalchemy. MetaData()
class Album(ormar. Model): ormar_config=ormar. OrmarConfig データベース=データベース、 metadata=メタデータ, tablename="アルバム" )
1 2 3
id: int=ormar.Integer(プライマリキー=True) name: str=ormar.String(max_length=100) お気に入り: bool=ormar.Boolean(default=False)パラメータ={ タイトル: Dark Side of the Moon "お気に入り": True, }
ormar<0.20
アルバム=アルバム.構築(**params)
ormar>=0.20
アルバム=Album. model_structure(**params)
構築の詳細については、pydanticドキュメントを参照してください。
-
0.12.2
✨特徴
- FastAPIサポートを最新バージョンにアップグレード(0.97.0)#1110
- Python 3.11のサポートとテストを追加#1110
0.12.1
✨特徴
- モデルと関連するモデルの再帰的な読み込みとキャッシュのおかげで、モデルを読み込む側のパフォーマンスが飛躍的に向上しました。(@erichaydel-ありがとう!)#853
💬内部構造
- 実装された傾向の変化のパフォーマンス効果を比較するためのベンチマーク(@erichaydelによって再び-ありがとう!)#853
0.12.0
✨大きな変化
- Queryset. bulk_createは、空のモデルリストでModelListEmptyErrorをスローするようになりました(@ponytailerによる-ありがとう!)#853
✨特徴
- Model. upsert()は、プライマリキーが設定されているかどうかに関係なく、挿入モデルを更新できるフラグ__force_save__:boolを処理するようになりました。 このフラグを設定すると、更新ごとに挿入されたモデルに対して2回クエリ->getを実行してモデルが存在するかどうかを確認し、後でそれに応じて更新/挿入することに注意してください。第889章
🐛修正
- (@Abdeldjalil-Hによって-ありがとう!)#870
- uuidを含む設定済みpksを保存しないモデルの保存に関する問題を修正#885
- 除外順序に基づく誤った関係の除外を修正#779
- プロパティ_fieldが正しく継承されていない問題を修正#774
0.11.3
✨特徴
- は、ForeignKeyにon updateとon deleteの参照操作を記録し、関係の動作を指定するための参照アクション列挙を提供します(@SepehrBazyarによる-ありがとう!)#724
- モデルMetaでサポートされている制約にCheckColumnを追加します(@SepehrBazyar-thank!)#729
🐛修正
- クエリ結果を0に制限する修正は、空のリストを返す必要があります(@SepehrBazyar-ありがとう!)#766
💬他
- ドキュメントにダークモードを追加します(@SepehrBazyar-Thank you!)#717
- aiomysql依存関係の更新#778
0.11.2
🐛修正
- データベースドライバの修復が必要であり、オプションである必要があります#713
- postgresでlimit_raw_sqlフラグのない制限クエリのブールフィールドの問題を修正しました#704
- アーキテクチャへのenum_classオーバーフローによって引き起こされるOpen APIのエラーを修正#699
0.11.1
🐛修正
- pydantic 1.9で導入されたディープレプリケーションの問題を修正#685
0.11.0
✨大きな変化
- Python 3.6のサポートを放棄する
- Queryset. get_or_createは、モデルが作成されたかどうかを示すモデルとブール値を含むタプルを返します(@MojixCoderによる-ありがとう!)#554
- Queryset. count()は、デフォルトで異なる親モデルの行の数を計算するようになりました。すべての行をユニーク=Falseに設定することで計算できます(@erichaydel-ありがとう)#588
✨特徴
- Python 3.10のサポートが追加されました
🐛修正
- saveとbulk_createで一貫性のないJSONフィールドの動作を修正#584
- 最大再帰エラーを修正#580
0.10.25
✨特徴
- はModel. Metaにqueryset_classオプションを追加し、QuerySetをモデルに簡単に置き換えることができます(@ponytailer-ありがとう!)#538
- を使用すると、追加のkwargsをIndexColumnsに渡すことができ、これらのインデックスカラムはsqlalchemyIndexに渡されます(@zevisert-ありがとう)#575
🐛修正
- 修正されたJSONフィールドの空の設定#529
- は、jsonの代わりにorjsonを使用したバッチ操作でのbytes/strの不一致を修正しました(@ponytailerによる-ありがとう!)#538
0.10.24
✨特徴
- post\bulk\update信号を追加します(@ponytailer-ありがとう!)#524
🐛修正
- pydantic==1.9.0#502のサポートを修正しました
- 日付時刻のタイムゾーンの問題を修正#504
- クエリ生成からテキストバインディングを削除して、postgres配列#/tophat/ormar-postgres-extensionsをアンロックします
- JSONフィールドのバッチ更新を修正#519
💬他
- は、databaseexecute_manyの次善の実装をバイパスすることで、bulk_createのパフォーマンスを向上させます。(@Mng-dev-aiありがとう!)#520
- 衝撃分。必要なデータベースのバージョンは>=5.4です。
0.10.23
✨特徴
- 列の作成時にsqlalchemyにコメントを渡す機能を追加#485
🐛修正
- LargeBinaryフィールドが空になる可能性があるのを修正#409
- ormar. Modelを選択可能にする#413
- first()とget()はパラメータなしでユーザーが設定したメインモデルの順序を尊重し、メインキー(それぞれascとdesc)#453に戻る
- postCongressでエイリアス以外の接続句への不適切な参照を修正する#455
0.10.22
🐛修正
- 親ormarモデルを設定するときにベリファイアが継承されないホットフィックス#365
0.10.21
🐛修正
- コンストラクタクラスメソッドのormar実装を追加します。これにより、入力を検証せずにモデルインスタンスを構築して、プロセス全体を高速化できます(データが検証されている場合)#318
- は、get_pydantic#365を使用して新しく作成されたpydanicモデルを生成する際に、ormarモデルからフィールド検証器を「継承」する問題を修正した
0.10.20
✨特徴
- は、Extraを受け入れる追加パラメータをModel. Metaに追加します。無視とExtra。禁止(デフォルト)、ormarモデルに渡された追加フィールドを無視するか、例外が発生したときに例外#358をスローします
🐛修正
- フィールドが空で、オプションが設定されている場合、「なし」#354は許可されません
- 移行の問題を回避するために、自動増分と明示的に空に設定できるかどうかに関係なく、常にプライマリ_keyを非空に設定します#348
0.10.19
✨特徴
- メタのサポートを追加します。制約#307で一意ではない複数の列のIndexColumns
- はsql_nullableフィールド属性を追加して、pydanticモデルと基礎となるsql列に異なるnull可能な設定を設定できるようにします#308
🐛修正
- パフォーマンス向上のためのグラフキャッシュの有効化#337
- 空の可能性のあるフィールドに関するドキュメントの明確化と修正#339
💬他
- サポートされているデータベースのバージョンを<=5.2にアップグレードします。
0.10.18
🐛修正
- pydanticモデルのフィールド順序を修正する#328
- データベースの修復0.5.0サポート#142
0.10.17
✨特徴
- モデルフィールドの上書きを許可するデフォルトのpydanticタイプ#312
- sqlalchemy>=1.4のサポートを追加(データベース>=0.5.0が必要)#142
0.10.16
✨特徴
- を使用すると、独自のpydantic構成をormar. Modelに渡すことができます。これは、@aturalethicによってデフォルトの構成とマージされます(ありがとう!)#285
- @ProgrammerPlus 1998でSmallIntegerフィールドタイプを追加します(ありがとう!)#297
🐛修正
- openapiパターンの生成は、パターン#291で直接公開されている古いpydanticフィールドパラメータを削除することによって修正されます
- モデルによって自動的に生成された不要な警告を修正#295
0.10.15
🐛修正
- ネストされたモデルを使用してpydanticモデルツリーを生成する問題を修正しました(@pawamoy-ありがとう!)#278
- プライマリキーフィールドの欠落に関する警告で欠落しているf文字列#274を修正しました
- 外部キー値をリレーションシップとして渡す修正(追加の保護、最新バージョンで修正されました)#270
0.10.14
✨特徴
- を使用すると、time zone: bool=Falseパラメータをタイムゾーン認識データベース列のDateTimeおよびTimeフィールド#264に渡すことができます
- は、値を文字列#79に変換するのではなく、日時でフィルタリングできるように、日時、日時、および日時をDateTime、Time、およびDateフィールドに渡すことができます
🐛修正
- サイコプグ2からサイコプグ2バイナリへの依存関係を修正する#255
0.10.13
✨特徴
-
は、selectとprefetchでフィールドアクセサを渡すことを許可します。Pythonスタイルのselectは#225です。
-
前に:
await Post. object.select_関連(["著者","カテゴリ"]).get() await Author. object.prefetch_関連("post__カテゴリ").get()
-
現在も:
Post. objectを待っています。select_Post.author([,Post.カテゴリ]).get() await著者.オブジェクト. prefetch_関連(著者.投稿.カテゴリ).get()
-
🐛修正
- 継承されたプライマリキーのデフォルト値を上書きする修正#253
0.10.12
🐛修正
- in itを使用しないQuerySet. createメソッドの修正(カスタムが提供されている場合)#245
- ForwardRefManyToMany関係設定のバグを修正するpydanticタイプ#250
0.10.11
✨特徴
- は、値と値_listをQuerySetとQuerysetProxyに追加し、クエリ#223から元のデータを返すことができます。
- クエリからタプルリストまたは辞書リストを返すことができます
- データをormarモデルに解析するため、検証もスキップします
- リレーショナルチェーン間のモデルを除外できるため、必要な列のみを抽出できます
- 列が1つだけ抽出された場合、values_listを使用すると結果を平坦化できます。
🐛修正
- ForwardRef#226を使用してm2 mリレーショナルモデルを介して自動作成する問題を修正しました
0.10.10
✨特徴
- はget_pydanticフラグを追加し、ormar. Modelから同等のpydanticモデルツリーを自動生成できるようにします。この新しく生成されたモデルツリーは、データに含めたくないフィールドを除外するためのリクエストとレスポンスで使用できます。
- 継承プロセス中に親モデルからフィールドを除外できるようにするために、モデルMetaにout put_parent_fieldパラメーターを追加します。 モデルとミックスインを組み合わせるのがベストプラクティスですが、似たようなモデルがたくさんあり、異なるモデルが1つしかない場合は、これを実現するための便利なツールになる可能性があります。
🐛修正
- ページングとリレーションシップを持つ空のフィルターを修正しました(@erichaydel提供)#214
-
216より前に保存されていない場合、リレーションシップの反対側に子オブジェクトが保存されない問題を修正しました
💬他
- ドキュメントのfastapiセクションを展開して、fastapiのリクエストとレスポンスでのormarの使用例を示します。
- デフォルト値、ForeignKey. addなどに関するドキュメントを改善しました。
0.10.9
重要なセキュリティ修正
- セキュリティの脆弱性を修正するためにpydanticピンを更新するCVE-2021-29510
修正されたpydanticバージョンに更新することをお勧めします。0.10.9では、ormarは固定依存関係の項目に脆弱性があるバージョンを除外します。
🐛修正
- LargeBinaryのOpen APIアーキテクチャを修正#204
0.10.8
🐛修正
- pk_onlyサブモデルのデフォルト値#202を修正しました
- LargeBinaryフィールドを修正するためにbase 64 strを使用するmypy#199
- Base 64 str表現を使用したLargeBinaryフィールドのOpen APIアーキテクチャ形式の修正#199
- Base 64 str表現を使用したLargeBinaryフィールドのOpen API選択エンコーディングを修正しました
0.10.7
✨特徴
- は
exclude_primary_keys: bool = Falseをdict()メソッドとして追加し、結果辞書のすべての主キーカラムを除外できるようにします。第164章 - は
exclude_through_models: bool = Falsedict()のフラグを追加して、ManyTomany関係からすべてのモデルを除外できるようにします#164 represent_as_base64_str: bool = FalseにバイトLargeBinaryフィールドをbase 64エンコードされた文字列に変換できるパラメータを追加します。プロパティにアクセスすると、文字列はdict()で返され、文字列は設定時にバイトに変換されます。データベース内のデータはバイトで格納されます。 第187章- pkエイリアスを追加して、Model.pkがフィルターとorder by句のフィールドにアクセスできるようにします(pythonスタイル)
🐛修正
- LargeBinaryフィールドのmax_lengthのデフォルトのNoneオプションを削除する#186
- 文字列フィールドmax_lengthのデフォルトのNoneオプションを削除します
💬他
- ドキュメントにdict()パラメータのガイドと例を提供します
- マジックメソッドのプロパティの取得/設定を記述子に再構築->大幅なパフォーマンス向上
0.10.6
✨特徴
-
LargeBinary(max_length)フィールドタイプ#166を追加
-
は、#160で廃止されたpydantic_onlyプロパティの代わりに、モデルを含む通常のpydanticフィールドのサポートを追加しました。 Pydanticフィールドは、ormarフィールドの隣にあるpydanticモデルと同じように通常宣言する必要があります。つまり、次のいずれかがtrueである必要があります。
- ormarモデルで宣言されたpydanticフィールドはオプションである必要があります(デフォルトはNone)
- pydanticフィールドはデフォルト値を設定する必要があります
- pydanticフィールドにはデフォルトの_factory関数セットがあります pydanticフィールドを持つ* のormar. Modelは、__in it__()を上書きし、そこに値を提供する必要があります
上記のormar(またはむしろpydantic)のいずれも、データベースからのデータの読み込み中に失敗せず、宣言されたpydanticフィールドに必要な値が不足している場合。
-
Ormarは、ネストされたモデルを含むopenapiパターンの意味のある例を提供するようになりました。dict()やselect/load_allと同じアルゴリズムを使用して、参照せずに関連するモデルを反復処理します。例はfastapiにもあります。第157章
🐛修正
- デフォルトでは、pydanticは割り当て中にフィールドを検証しません。これはORMにとって理想的な設定ではありません。現在、すべてのormar. Modelsは割り当て中に検証をオンにしています(model.column='value'など)
💬他
- readme#180のクイックスタートにデータベースへの接続を追加します
- Open APIアーキテクチャには、説明としてormar. Modelドキュメント文字列が含まれなくなりました。独自のドキュメント文字列を指定しない場合は、モデル名のみを指定します。
- いくつかのパフォーマンスの改善。
0.10.5
🐛修正
- fastapi-pagination#73のバグ修正
- は、QuerySet. all()およびQuerysetproxy.all()の戻り値のList[オプション[T]]から不要なオプション#174を削除します
- テストカバレッジの実行は、ギットハブ操作ではなく、内部prsでのみ公開されます。
0.10.4
✨特徴
- Pythonスタイルの追加
filterとorder_byはdunderで区切られた文字列の代わりにフィールドアクセスを使用します。第51章 属性アクセス(ドットシンボリックチェーン)を介した* アクセスフィールドを使用して、FilterGroups(ormar。and_およびormar。or_)を構築できます- フィールドアクセスは、一連のPython演算子をオーバーロードし、**kwargsのdunderで区切られたパラメーター名と同じ機能を可能にする一連の関数を提供します。つまり、モデルAlbumに関連するサンプルモデルTrackから
クエリより多くのオプションがあります。
- 正確-値と正確に一致し、SQL列=
- 旧:アルバム__名前__正確='Malibu'
- NEW:Track.album.name=='Malibuと書くこともできます
- 正確に一致するSQL列=
(大文字と小文字を区別しない) - 旧:アルバム__name__i正確='malibu'
- 新:書くこともできます
Track.album.name.iexact('malibu')
- には、'%
%'のようなSQL列が含まれています。 - 旧:アルバム__名__インクルード='Mal'
- NEW:Track.album.name%'Mal')と書くこともできます
- 新:書くこともできます
Track.album.name.contains('Mal')
- icontains-sql列LIKE'%
%'(大文字小文字を区別しない) - 旧:アルバム__name__icontains='mal'
- 新:書くこともできます
Track.album.name.icontains('mal')
- -sqlで
column IN (<VALUE1>, <VALUE2>, ...)- 古い:
album__name__in=['Malibu', 'Barclay'] - 新:書くこともできます
Track.album.name << ['Malibu', 'Barclay'] - 新:書くこともできます
Track.album.name.in_(['Malibu', 'Barclay'])
- 古い:
- isnull SQL列IS NULL(およびSQL列IS NOT NULL)
- 旧:__name__isnull=True(isnotnullAlbum__name__isnull=False)
- NEW:Track.album.nameと書くこともできます
- New:Track.album.name. isnull(True)と書くこともできます
- 新しい: not nullも書けます
Track.album.name.isnull(False) - 新: not nullも書くことができます~(Track.album.name>>None)
- 新しい: not nullも書けます
~(Track.album.name.isnull(True))
- gt-sql列>
(より大きい) - 古い: position__gt=3
- NEW:Track.album.name>3と書くこともできます
- gte-sql列>=
(以上) - 古い: position__gte=3
- 新:Track.album.name>=3と書くこともできます
- lt-sql列<
(下) - 古い: position__lt=3
- NEW:Track.album.name<3と書くこともできます
- lte-sql列<=
(以下等しい) - 古い: position__lte=3
- NEW:Track.album.name<=3と書くこともできます
- startswithsql列LIKE'
%'(正確な開始マッチング) - 旧:アルバム__name__startswith='Mal'
- 新:書くこともできます
Track.album.name.startswith('Mal')
- istartswith-sql列LIKE'
%'(大文字小文字を区別しない) - 古い:
album__name__istartswith='mal' - 新:書くこともできます
Track.album.name.istartswith('mal')
- 古い:
- endswith-sql列LIKE'%
'(完全終了マッチング) - 旧:アルバム__name__endswith='ibu'
- 新:書くこともできます
Track.album.name.endswith('ibu')
- iendswith-sql列LIKE'%
'(大文字小文字を区別しない) - 旧:アルバム__名__iendswith='IBU'
- 新:書くこともできます
Track.album.name.iendswith('IBU')
- 正確-値と正確に一致し、SQL列=
- フィールドアクセスは、一連のPython演算子をオーバーロードし、**kwargsのdunderで区切られたパラメーター名と同じ機能を可能にする一連の関数を提供します。つまり、モデルAlbumに関連するサンプルモデルTrackから
クエリより多くのオプションがあります。
- filterGroupsをfilter()とout of()で提供できるだけでなく、次のようにも利用できます。
- 得る()
- 取得またはなし()
- 取得または作成()
- 最初の()
- 全部()
- 削除()
- FilterGroups(ormar. and_およびormar.or_)を使用して、次のものを使用できるようになりました。
- &-次の層のネストではなくand_として
- |-次の層のネストではなく、「or_」として
- ~-フィルターグループとしての否定
-
複数のフィルタを1つの条件に結合するには、&(sql AND)と|(sqlまたは)を使用します
1 2 3 4 5 6 7 8 9 10 11
以下のクエリは同等です: #sql:(product.name='Test'AND product. rate>=3.0) #ormarオプション1-古いもの Product. object.filter(name='Test',rating__gte=3.0).get() #ormarオプション2-古いもの Product. object.filter(ormar.and_(name='Test',rating__gte=3.0)).get() #ormarオプション3-新しいオプション(フィールドアクセス) 製品.オブジェクト.フィルター((Product.name=='テスト')&(製品.レーティング>=3.0)). get() -
ネストされた複雑なフィルタにも適しています
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
以下のクエリは同等です: #sql:(product.name='Test'AND product. rate>=3.0) #OR(categories.nameIN('おもちゃ','本')) #ormarオプション1-古いもの 製品.オブジェクト.フィルター(ormar. or_( ormar. and_(name='Test',rating__gte=3.0), カテゴリ__name__in=['おもちゃ','本']) ). get() #ormarオプション2-新しいもの(入れ子になっているか `|` を使用する代わりに) 製品.オブジェクト.フィルター( ormar. and_(name='Test',rating__gte=3.0)| ormar. and_(カテゴリ__name__in=['おもちゃ','本']) ). get() #ormarオプション3-新しいオプション(フィールドアクセス) 製品.オブジェクト.フィルター( ((Product.name='テスト')&(製品の評価>=3.0))| (Product.categories.name<<['おもちゃ','本']) ). get() -
フィールドアクセスを使用して、order_by()にOrderActionsを提供できるようになりました
- 昇順:
- 古い:
Product.objects.order_by("name").all() - 新しい:
Product.objects.order_by(Product.name.asc()).all()
- 古い:
- 降順に並べ替えます:
- 古い:
Product.objects.order_by("-name").all() - 新しい:
Product.objects.order_by(Product.name.desc()).all()
- 古い:
- もちろん、異なるモデルと多くのorder_byを組み合わせることもできます。
Product.objects.order_by([Product.category.name.asc(), Product.name.desc()]).all()
- 昇順:
🐛 修正する
- 真のバグではなく、矛盾しています。ネストされたモデルを持つフィルターを提供します。つまり、アルバム__カテゴリー__name='AA'アルバムとカテゴリモデルがselect_がない場合は自動的にそこに追加されます。FilterGroupsにも同じ機能は適用されません(and_ または_)、動作するようになりました(FilterGroupsを返すPythonスタイルのフィルターにも適用されます)。
0.10.3
✨ 特徴
-
foreignKeyとManyTomanyがskip_逆: bool=Falseフラグ#118をサポートするようになりました。skip_逆フラグを内部で設定した場合でも、リレーションシップの反対側にフィールドが登録されたままなので、次のことができます。
- リバースモデルの関連するモデルフィールドによるフィルタリング
- order_byリバースモデルの関連するモデルフィールド
しかし、あなたはできません:
- 関連_nameを使用して、リバースモデルから関連フィールドにアクセスします
- モデルの反対側から相関を選択しても、返されたモデルは逆インスタンスに入力されません(接続がブロックされないため、_byでフィルタリングして注文できます)
- この関係はdict()とjson()には入りません
- がdict()またはjson()から(fastapiを介しても)入力された場合、ネストされた関連オブジェクトを渡すことはできません。pydantic構成の追加設定によっては、無視されるか、エラーが発生します。
-
Model.save()は現在、データツリー全体を一度に保存できます。#148の意味は:
-
関係を保持するために、最初にマスターモデルまたは関連モデルを保存する必要があるかどうかを知っています
-
メインモデルを保存する場合
- 保存されていない、
- PK値がありません。
- またはsave_all=Trueフラグが設定されています
このような場合、保存を2つの呼び出し(save()とsave_ated())に分割する必要はありません
-
多対多の関係もサポートしています
-
また、m2m関係のオプションのThroughモデル値もサポートしています
-
モデルリレーショナルフィールド名を使用してカスタマイズする機能を追加します。
-
デフォルトでは、モデルリレーションシップ名による関連モデル名はデフォルトで小文字です。したがって、次の例では次のようになります。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
。。。 ##コース宣言省略 class Student(ormar. Model): クラスMeta: データベース メタデータ id: int=ormar.Integer(プライマリキー=True) name: str=ormar.String(max_length=100) コース=ormar. ManyTomany(コース) ##次のようなデフォルトのスルーモデルを生成します(例を簡略化)。 class StudentCourse(ormar. Model): クラスMeta: データベース メタデータ tablename="学生コース" id: int=ormar.Integer(プライマリキー=True) student=ormar. ForeignKey(学生)##デフォルトの名前 コース=ormar. ForeignKey(コース)#デフォルト名 -
Throughモデルのフィールド/リレーションシップ名をカスタマイズするには、ManyTomanyの新しいパラメーターを使用できます。
- through_Relations_name-ManyTomanyを宣言するモデルへのフィールド名
- through_逆_関係_name-ManyTomanyにつながるモデルのフィールド名
例:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22
。。。 #コース宣言省略 class Student(ormar. Model): クラスMeta: データベース メタデータ id: int=ormar.Integer(プライマリキー=True) name: str=ormar.String(max_length=100) コース=ormar. ManyTomany(コース、 through_Relations_name="student_id", through_逆関係名="コースID") #以下のようなデフォルトのスルーモデルを生成します(例を簡略化)。 class StudentCourse(ormar. Model): クラスMeta: データベース メタデータ tablename="学生コース" id: int=ormar.Integer(プライマリキー=True) student_id=ormar. ForeignKey(Student)#through_Relations_nameで設定 Course_id=ormar. ForeignKey(コース)#through_逆関係名で設定
🐛 修正する
- 弱い参照エラー#118を修正する
- pydantic Configを設定したときにThrough fieldによって引き起こされるエラーを修正します。extra="forbid"
- は、pydantic. PrivateAttrが__in it__で初期化されていないエラーを修正します#149
- はdict()でpydantic-typeが除外したエラーを修正し、__all__キーが機能しない
💬その他
- モデルを導入するためのsqlalchemy-toormar自動翻訳者へのリンク
- ormarをサポートするfastapiエコシステムライブラリへのリンクを提供します
- ドキュメントへのトランザクションの追加(データベースサポート)
0.10.2
✨ 特徴
Model.save_related(follow=False)は現在、2つの追加パラメータを受け付けています:Model.save_related(follow=False, save_all=False, exclude=None)。- save_all: bool->デフォルトでは(したがってsave_all=False)ormarは保存されていないモデル(したがって新しいモデルまたは更新されたモデル)を挿入するだけで、save_all=Trueを使用すると、保存状態に関係なく、関連するすべてのモデルが保存されます 次の便利な更新されたモデルは、バックエンドで変更されないようにAPIから呼び出されます。
exclude: Union[Set, Dict, None]->設定/辞書follow=Trueとsave_all=Trueを使用しても、保存から除外する関係は保存されません。ネストされた関係を除外するには、ネストされた辞書を渡します。例:exclude={"child":{"sub_child": {"exclude_sub_child_realtion"}}}許可されている値は、(QuerySetから)field/clude_fieldメソッドスキーマに従うため、質問がある場合は、クエリのドキュメント->フィールドサブセットの選択->フィールドを参照できます。
- Model. update()メソッドは、更新するカラム名のリストを受け付ける_column:List[str]=Noneパラメータを受け付けるようになりました。このパラメータが有効な場合、それらのカラムのみがデータベースで更新されます。 update()はモデルのインスタンスを更新しないため、_columnリストで渡された列数よりも多くの列数を変更すると、モデルインスタンスの値がデータベースと異なることに注意してください。
- Model. model_dump()メソッドには、以前は直接関連するモデルまたはネストされたモデルのみが含まれていました(空ではなく仮想でない場合)。これまでループなしでアクセスされていなかったすべての関連モデルがdict()に含まれるようになりました。 より多くのデータが辞書にダンプされるので、これは壊れないはずですが、失われてはいけません。
QuerySet.delete(each=False, **kwargs)は、以前はフィルタを渡すか(**kwargsを介して、または別のfilter()として呼び出す)、each=Trueを設定する必要がありましたが、NOTフィルタを生成する排他的()呼び出しも受け入れられるようになりました。 したがって、テーブル全体または少なくとも1つのフィルタリング/除外句を削除するには、each=Trueを設定する必要があります。- と同じことが
QuerySet.update(each=False, **kwargs)にも当てはまります。以前は、フィルターを渡すか(**kwargsを介して、または別のfilter()として呼び出す)、each=Trueを設定する必要がありました。これで、NOTフィルターを生成するために使用できるようになりました。 )を呼び出します。したがって、テーブル全体または少なくとも1つのフィルタリング/除外句を更新するには、each=Trueを設定する必要があります。 - 同じことが適用されます
QuerysetProxy.update(each=False, **kwargs)また、フィルタを渡すように求められる前に(**kwargsを個別のfilter()として呼び出すか、each=Trueを設定することで、NOTフィルタを生成するout()呼び出しも受け付けるようになりました。したがって、テーブル全体または少なくとも1つのフィルタ/除外句を更新するにはeach=Trueを設定する必要があります。
🐛 修正する
- fkカラムのデータベースエイリアスが異なる場合のQuerysetProxyでの不適切なリレーショナルフィールド解析を修正します。
- dict()を呼び出す際にループを伴う非常に複雑なモデル構造の再帰エラーを修正しました。
- 2つの非リレーショナルフィールドがリレーショナルフィールド(つまりJSON)でない場合に、クエリ結果にマージ(追加)されるエラーを修正しました
- リストから辞書への翻訳中にチェーン内で同じリレーションシップ名が使用され、モデルが異なるバグを修正しました
- bulk_createがproperty_field修飾子メソッドとpydanticフィールドを保存しようとしたときのエラーを修正しました
- 逆関係の深い入れ子になったチェーンの誤ったマージを修正します
💬その他
- パフォーマンスの最適化
- テスト領域に基づいてテストをパッケージに分割します
0.10.1
特徴
- は、get_or_none(**kwargs)メソッドをQuerySetとQuerysetProxyに追加します。 これはget(**kwargs)とまったく同じですが、条件に一致するデータベースレコードがない場合、get_or_noneはormar. NoMatch例外をスローせず、単にNoneを返します。
修正する
- postgresでorder_by句の方言関連のカラム名とテーブル名参照が正しく動作しない問題を修正しました。
0.10.0
壊す
- 長い間推奨されていなかったフィールド定義表記のサポートが削除されました。この表記では、ormarフィールドをタイプヒントとして使用します。
test_field: ormar.Integger() = None - の改良された型ヒント->mypyは、関連するモデルフィールド(ForeignKeyとManyTomany)とQuerySetメソッドの戻り値の型を正しく解析します。言及されているものは、ormar. Model型ではなく正しいモデル(つまりBook)を返すようになりました。 リレーションシップとQuerysetProxyメソッドの反対側に問題が残っており、それを緩和するためにAnyの型ヒントを返すようになりました。#112を部分的に修正しました。
特徴
select_all(follow: bool = False)QuerySetとQuerysetProxyを追加するメソッドです。モデルのload_all()メソッドに似ていますが、クエリで直接使用できます。 デフォルトでは、select_all()は直接関連するモデルのみを追加します。follow=Trueの場合、関連するモデルの関連モデルも追加され、リレーションシップでループは発生しません。 select_all()はfield()やorder_by()などのQuerySet(またはプロキシ)を返すため、非同期モデルではなく終了することに注意してください。
内部構造
- ormarフィールドは、Meta. model_fieldディクショナリのクラスとして保存されなくなり、インスタンスとして保存されます。
0.9.9
特徴
- リレーションシップとモデルのデフォルトの順序を変更する可能性を追加します。
- モデルの順序を変更するには、order_by=[column]where column: List[str]をモデルメタクラスに渡します
- order_byの関係を変更するには、order_by=[列]where列: List[str]を渡します
- 逆の関係を変更するにはorder_by関連する注文を渡す_order_by=[column]where column: List[str]
- パラメーターは、カラム名または-{col_name}で降順にソートできます
- リレーションシップでは、直接関連するモデル列、または複数対複数の列の場合はモデル列でのみソートできます
"{through_field_name}__{column_name}" - order_by句の適用順序は以下の通りです:
- クエリでorder_by()呼び出しを明示的に渡す
- 存在する場合、関係はorder_byを通過します。
- モデルメタクラスorder_by
- モデルの主キー列asc(バックアップ、上記のいずれも提供されていない場合に使用)
- 4つの新しい集約関数を追加します->min、max、sum、avgはそれぞれそれらの対応するSQL等価物です。
- 関連するカラムを含む1つ以上のカラム名を渡すことができます。
- これまでのところ、渡された各列は個別に集計されています(したがって、sum(col 1+col 2)は不可能です。sum(col 1、col 2)を使用して、Pythonで2つの返される合計を追加できます)
- 数値以外の列の合計と平均を計算することはできません
- 列を集計する場合は、結果として単一の値を直接返します
- 複数のカラムを集約する場合は、カラム:結果ペアを含む辞書を返します
- は4つの新しい信号を追加しました->pre\realation\add、post\realation\add、pre\realation\remove、post\realation\remove
- の新たに追加されたシグナルは、ManyTomanyリレーションシップ(両側)とforeignkeyリレーションシップ(公開されているQuerysetProxyと同じ)の反対側に対して送信されます。
- 信号は、次のパラメータを受け取ります: sender:Type[Model]-送信者クラス、instance:Model-関連するモデルのインスタンスを追加します。child:Model-追加中のモデル、関係_name:str-サブアイテムの関係を追加します 追加信号などの名前は、_kwargs:辞書-add()のkwargs辞書にも渡されます
変化する
- 作成、削除、更新時に多対多の関係のモデルをインスタンス化することで、プライマリキーとして自動増分intだけでなく、デフォルト機能を備えた任意の列タイプも提供できるようになりました。
- Throughモデルがインスタンス化されたので、Throughモデルの前後にシグナルを保存/更新/削除するためにサブスクライブすることもできます
- pre_updateシグナルレシーバーは、更新関数に渡される値のディクショナリであるPassed_argsパラメータも取得します(存在する場合)(それ以外の場合は空のディクショナリ)
修正する
- これで、値を抽出する前にpre_updateシグナルが送信され、渡されたインスタンスをその場で変更でき、変更されたフィールド値がデータベースに反映されます
- bulk_updateでUUID主キー列タイプを正しく使用できるようになりました
0.9.8
特徴
- データベースで選択したフィールドを暗号化する機能を追加します
- 少なくとも、暗号化_secretと暗号化_backendを提供する必要があります
- crypt_backendはormar. EncryptBackend列挙の一つ(NO NE、FERNET、HASH、CUSTOM)-デフォルト値:NO NE
- カスタムバックエンドを選択するときは、サブクラスormarのバックエンドクラスを指定する必要があります。field。EncryptBackend
- プライマリ_keyカラムとオフシリーズ(FKとM 2 M)を暗号化できません。
- HASHとFERNETの2つのバックエンドが提供されています
- HASHは一方向ハッシュ(パスワードなど)であり、検索時に復号化されることはありません
- FERNETは双方向暗号化/復号化バックエンドです
- FER NETバックエンドでは、暗号化値の一部がタイムスタンプであるため、フィルタリングの可能性が完全に失われることに注意してください。
- HASHバックエンドでは、完全な値でフィルタリングできますが、暗号化された値が比較されるため、インクルードなどのフィルターは機能しないことに注意してください
- 暗号化_バックエンドを追加すると、データベースのカラムタイプがTEXTに変更され、移行または手動で変更してdbに反映する必要があることに注意してください
修正する
- (高度/内部)は、動作を停止したカスタムsqlalchemyタイプ(types. TypeDecoratorサブクラスを介して)機能を復元するため、process\result\valueを呼び出すことはありません
0.9.7
特徴
-
メソッドをフィルタリングおよび除外するためにisnull演算子を追加します。
1 2
Album__name__isnull=True#(sql:album.nameはnull) Album__name__isnull=False#(sql:album.nameはnullではない)) -
は、ネストされた条件を持つ複雑なクエリを持つormar. or_とormar.and_関数の組み合わせに使用できるように追加します。例のクエリ:
1 2 3 4 5 6 7 8 9 10
本=( await Book. object.select_関連("著者") フィルタ( ormar.と_( ormar. or_(year__gt=1960,year__lt=1940), Author__name="J. R.R.トールキン", ) ) . all() )クエリで更新されたドキュメントを確認する->フィルターとソート->複雑なフィルター
その他
- がForeignKeyまたはManyTomanyにデフォルト値を設定すると、ModelDefinition例外が発生します。これは、現在(および過去に)サポートされていないためです
0.9.6
重要な
-
による多対多のリレーショナルモデルがオプションになりました。これを提供すれば、すべてが以前と同じように機能するので、これは大きな変更ではありません。したがって、モデル上の他のフィールドを「渡す」ことを望まない、または必要としない場合は、スキップできます。 自動的に作成され、alembicマイグレーションの例に含める必要があることに注意してください。既存のデータベースを削除する場合は、デフォルトの命名規則を確認して、既存のデータベース構造を調整してください。
Throughモデル名またはデータベーステーブル名をカスタマイズする場合でも、指定する必要があることに注意してください。
特徴
- は更新メソッドをQuerysetProxyに追加しました。これにより、ManyTomanyリレーションの親モデルと逆外部キーリレーションから直接関連モデルを更新できるようになりました。QuerySetupdateのような更新は更新されたモデルの数を返し、親モデルの関連モデルは更新されないことに注意してください。
親モデルで更新されたデータを取得するには、関連するモデル(
await model_instance.related.all())を更新する必要があります - は
load_all(follow=False, exclude=None)modelメソッドを追加し、モデルの現在のインスタンスと関連するすべてのモデルを1回の呼び出しでロードできるようにします。デフォルトでは直接関連するモデルのみをロードしますが、follow=Trueを設定するとツリーをトラバースします(ループを回避します)。 QuerySetと同じ除外パラメーターを渡すこともできます。 - 多対多関係のThroughモデルにフィールドを追加する可能性が追加されました:
- throughモデルフィールドの名前は、Throughクラスの小文字の名前です
- add(child,**kwargs)をリレーションシップで呼び出すと、他のフィールドを渡すことができます(QuerysetProxy上)
- キーワード引数の1つが値辞書を持つモデル名である必要がある場合、(QuerysetProxyで)create(**kwargs)をリレーショナルに呼び出すときに、他のフィールドを渡すことができます
- モデルフィールドから注文できます
- モデルフィールドでフィルタリングできます
- モデルからフィールドを含めたり除外したりできます
- スルーモデルは、関連するモデルにのみアタッチされます(つまり、AからBにクエリを実行する場合->Bのみ)
- パススルーモデルはリレーションシップなしで明示的に読み込まれることに注意してください->リレーションシップはManyTomanyフィールドに埋め込まれています。
- 以前はモデルを介してリレーショナルフィールドを宣言できなかったのと同じように、それらはormarによって入力されることに注意してください。しかし、そうしようとすると、ModelDefinitionErrorがスローされます
- 詳細については、更新されたManyTomanyリレーションシップドキュメントを確認してください
その他
- ドキュメントとAPIドキュメントを更新しました
- 再構築と最適化には、主にフィルター、除外、ソートの根拠が含まれます
0.9.5
修正する
- pydanticをバージョン1.8以上に更新した後にpydantic FieldInfoを作成する問題を修正しました
- 将来このような状況が発生しないように、必要な依存バージョンを固定します
0.9.4
修正する
- 複数のモデルが同じ関連モデルを参照する場合の自動ドキュメントのfastapi Open APIスキーマ生成を修正しました
0.9.3
修正する
- 初期化後に値を設定すると、JSONフィールドが二重にエスケープされる問題を修正しました
- Pydanticの内部構造により、JSONフィールドが空のフィールドに設定できない問題を修正しました
- JSONフィールドの選択検証を修正
- 初期化後にプロパティを設定したときに検証されなかったオプションを修正しました
- QuerySetの更新呼び出し中に検証されなかったオプションを修正しました
0.9.2
その他
- ドキュメント/READMEのクイックスタートを更新しました
- クエリのサブページへのリンクを含むドキュメントが更新されました
- コード気候とダウンロード量のバッジを追加しました
0.9.1
特徴
- Open API仕様にオプション値を追加して、結果スキーマのネイティブEnumフィールドのようにします。
修正する
- 特殊フィールドが初期化されていないが文字列などとして渡されている場合は、fastapiを使用して「修正」選択動作を使用します。
0.9.0
重要な
- ブレーキの修正:バージョン0.8.0、alembicまたはsqlalchemy. engineによる作成中に、データベース内に外国の_keys制約が生成されないようにするバグが発生しました。
- したがって、バージョン>=0.8.0を使用している場合は、ほとんどのormar関数が実行されているにもかかわらず、ormar(またはormar+alembic)で作成されたデータベースは関係なく、パフォーマンスとデータの観点から影響を受けるため、更新することを強くお勧めします。
- ormarを使用して既存のデータベースに接続する場合、パフォーマンスと整合性は良好であるはずですが、モデルの将来のすべてのスキーマ更新を反映するように更新する必要があります。
壊す
- ブレークスルー:すべての外部キーと一意の制約に名前が付けられるようになったため、alembicはデータベースに依存せずにデータベース内でそれらを識別できます
- の破壊:モデル構築中に、モデルのメタクラスにメタデータまたはデータベースが含まれていない場合、一般的なAttributeErrorではなくModelDefinitionErrorが発生するようになりました。
- の破壊:クエリを実行するためのエンコーディング/データベースには、sqliteバックエンド用の接続プールがありません。つまり、各クエリは新しい接続で実行され、デフォルトで各接続でオフになっているため、強制的な外部キー制約を有効にできません。
=0.9.0以降、これはormarで変更され、デフォルトでは各sqlite 3クエリは「PRAGMAforeign_keys=1;」で実行されるため、各sqlite 3接続はデフォルトでカスケードを含む外部キー制約を強制します。
その他
- APIドキュメントを更新します。
- データベースにfkを作成し、データベースにリンクするテストを追加します
0.8.1
特徴
- はForwardRefの処理について説明しています。これで、自己参照モデル、外部キー、多対多の関係を作成できます。ForwardRefはtoとthrough Modelで使用できます。
-
次のような複雑なリレーションシップを処理するために、1つのクエリで2つの同じリレーションシップ接続を実行する可能性を紹介します。
1 2 3 4 5 6 7
B=X=Y // A \ C=X=Y<=1つのクエリで1回だけXからYにリンクできるようになる前に 2つの異なる関係が使われない限り (名前の異なる2つのリレーションフィールド) -
ページとpage_sizeによる制限/オフセットを可能にするページングメソッドを導入します。QuerySetとQuerysetProxyで使用できます。
その他
- クエリと接続のリファクタリングとパフォーマンスの最適化。
- テストとpypiの設定にpython 3.9を追加します。
- APIドキュメントとドキュメントの更新->、つまりクエリドキュメントの分割。
0.8.0
壊す
- Break ing: remove()逆外部キーリレーションシップの子側の親は、同じモデルを複数回登録でき、ormarが親のどのリレーションシップから子を削除するかを知る必要があるため、リレーションシップ名を渡す必要があります。
- ブレーク:デフォルトでは、select_atedを使用して制限とオフセットを適用すると、接続前のマスターテーブルにのみ適用されます->行の総数が制限されるのではなく、マスターモデルの数だけが制限されることを意味します(クエリの最初のもの、それを構築するために使用されます)。 制限またはオフセット(またはその両方)にlimit_raw_sql=Trueフラグを使用して、データベース応答のすべてのローを制限することもできます
- 破壊: first()を発行すると、主キーascでソートされた最初の行が取得されます(したがって、挿入された最初の行(数字以外の主キーでは異なる可能性があります-文字列のアルファベット順))
- 破壊:フィルタなしでget()を発行すると、主キーdescでソートされた最初の行が取得されます(したがって、最後に挿入された行である必要があります(数字以外の主キーでは異なる可能性があります-文字列のアルファベット順))
- 破壊(内部): Metaに保持されているsqlalchemyカラム。カラムはテーブルにバインドされなくなったため、そこから直接カラムを取得することはできません
特徴
- 継承を紹介します。現在可能な継承には2種類あります。
- Mixins-ormar. Modelをサブクラス化しないでください。後で異なるモデルで使用されるフィールドを定義するだけです(たとえば、各サブモデルで作成された日付と更新された日付)。実際のモデルだけがテーブルを作成しますが、Mixinsのフィールドを追加します
- 具体的なテーブル継承-親がMetaクラスで抽象=Trueとしてマークされ、各子には親からの列と独自の子列を含む独自のテーブルがあり、Mixinsに似ていますが、親も(抽象的な)モデルです
- 詳細については、モデル->継承セクションのドキュメントを参照してください。
- QuerySet first()はprefetch_atedと一緒に使用できます
修正する
- メインモデルのorder byのorder_byの小さなバグを修正しました
- 同じモデルの複数の関連する_nameのprefetch_queryを修正しました。
- は、異なるモデルで同じ関連_nameを使用すると、同じ関連モデルが互いに上書きされ、ModelDefinitionErrorが発生し、名前を変更する必要がある問題を修正しました。
- 同じテーブルに複数のリンクを適用した場合にorder_by上書き条件が適用される問題を修正しました。
ドキュメント
- ドキュメントの分割とクリーンアップ:
- モデル部分をいくつかの小さな部分に分けます
- 関係部分を小節に分ける
- フィールド部分を小さな部分に分割します
- モデル継承セクションを追加します
- API(ベータ版)ドキュメントを追加する
0.7.5
- many_to_manyリレーションシップ接続で間違ったシリーズ名を修正しました(修正#73)
0.7.4
- 同じ関連モデル/テーブルとの複数のリレーションシップを許可します。
- many_to_manyリレーションシップ接続で使用されていたオフシリーズのバグを修正しました(修正#73)
- 同じモデルにもfk関係がある場合のm2 m関係の誤った関係群を修正しました。
- モデル上の同じテーブルに複数のリレーションシップがある場合は、ユーザーが関連する_nameを提供しているかどうかを確認します。
- 死んだ弱いエージェントモデルをより熱心にクリーンアップします。
0.7.3
- 元の文字列であるUUDI pkの設定で関連するモデルを取得する問題を修正しました(修正#71)
0.7.2
- pkのみを使用して関連するモデルを上書きする問題を修正
Model.update() with fields passed as parameters(修正#70)
0.7.1
- Model.save()でのみpkを使用して関連するモデルを上書きする問題を修正しました(修正#68)
0.7.0
- の破壊: QuerySetbulk_updateメソッドは、QueryDefinitionErrorではなく、渡された保存されていないモデルに対してModelPersistenceErrorをトリガーするようになりました
- ブレークスルー:不明なフィールド名を使用してモデルを初期化すると、KeyErrorではなくModelErrorが発生するようになりました
- は、事前に定義されたリスト信号とデコレータを持つ信号を追加します: post\delete、post\save、post\update、pre\delete、pre\save、pre\update
- py. types edを追加し、setup.pyを変更してmypyをサポートします
- パフォーマンスの最適化
- ドキュメントの更新
0.6.2
- パフォーマンスの最適化
- pydantic_onlyフィールドが必要なバグを修正
- は、Model. model_dump()およびfastapiレスポンスに含まれるプロパティとして関数を登録するプロパティ_fieldデコレータを追加します
- ドキュメントの更新
0.6.1
- pydanticがデフォルト値を設定しないように、空になる可能性のあるフィールドを除外するように明示的にNoneを設定します(修正#60)。
0.6.0
- 破壊:データベースからインスタンスローを削除するときにinstance. load()を呼び出すと、ValueErrorではなくNoMatchがスローされるようになりました
- 破壊: ReverseForeignKeyリレーションシップで追加と削除を呼び出すと、データベース設定が更新され、fkカラムのサブモデルが削除されるようになりました
- ブレークスルー: ReverseForeignKey関係は、ManyTomany関係と同様にQuerySetProxy APIを公開するようになりました
- 破壊: ManyTomanyから関連モデルをクエリすると、親モデルに読み込まれている関連モデルのリストがクリアされます。
- の例: post。カテゴリー。最初()は、関連するモデルのリストとしてpost。カテゴリーを設定します->最初()が返すモデル
- の例2:投稿に4つのカテゴリがある場合、len(post。カテゴリ)==4は
post.categories.limit(2).all()を呼び出します->2つのサブプロセスのみがロードされますassert len(post.categories) == 2
- は、取得_or_create、更新_or_create、field、除外_field、除外、prefetch_ated、および順序_byをQuerySetProxyに追加したため、これらのメソッドをリレーショナルから直接使用できるようになりました
- ドキュメントの更新
0.5.5
- は、UUIDカラムを移行する際のalembic自動生成の問題を修正しました。sqlalchemy CH AR(32)またはCH AR(36)のみを生成する必要があります
- それを動作させるには、user_module_prefix='sa'を設定する必要があります。(sqlalchemy_module_prefixオプション(デフォルトは「sa」)と等しくなければなりません。)
0.5.4
-
を使用すると、uuid_format(「16進数」(デフォルト)または「文字列」を許可)をUUIDフィールドに渡して保存形式を変更できます。 デフォルトでは、フィールドは16進数形式(ダッシュなしで32文字にトリミング)で保存されますが、format='string'を渡すと、36(ダッシュ付き)を使用して既存のデータベースやその他のライブラリを調整できます。
サンプル:
- 16進値=c616ab438cce49dbbf4380d109251dce
- 文字列値=c616ab43-8cce-49db-bf43-80d109251dce
0.5.3
- Model. model_dump()メソッドで除外パラメータを無視し、辞書パラメータを含まないバグを修正しました。
0.5.2
- 別のクエリで後続のモデルをロードするprefetch_atedメソッドが追加されました。
- ドキュメントの更新
0.5.1
- トラビスの代わりにギットハブアクションに切り替えます
- ドキュメントのバッジを更新します
0.5.0
- 保存状態が追加されました->ModelInstanceを使用してモデルが保存されているかどうかを確認できます。保存されたプロパティ
- 挿入メソッドをモデルに保存/更新/ロード/更新した後、モデルを保存します
- モデル保存後
create/get/first/all/get_or_create/update_or_createメソッド - モデルはbulk_updateとbulk_createに渡されたときに保存されます
- ManyTomany関連オブジェクトを追加/削除した後、モデルを保存します(モデルインスタンスによる自動保存/削除)
- 独自のフィールドを変更してもモデルは保存されません(Model.pkエイリアスとしてのpkを含む)
- ForeignKey関連オブジェクトを追加/削除した後、モデルが保存されない(fk列が保存されない)
- は__in it__を使用してインスタンス化した後、モデルを保存しません(QuerySet. createを使用しないか、saveを呼び出す前)
- はModel. upsert(**kwargs)を追加し、pkが設定されていなければsave()を実行し、そうでなければupdate(**kwargs)を実行する
- エクストラ
Model.save_related(follow=False)は、すべてのリレーション内の関連するすべてのオブジェクトを反復し、保存されているかどうかを確認します。そうでない場合は、各オブジェクトに対してupsert()を呼び出します。 - 破壊:保存されていない(pkがNone)モデルを多対多の関係に追加/削除すると、追加によって例外が発生します
- ディクショナリとコレクションをfieldに渡すことを許可します
- strとリストを自動的にフィールドと除外フィールドの辞書に変換します
- 破壊:ネストされたモデルをfieldとexcre_fieldに渡すことは、ターゲットモデル名ではなく、関連する外部キー名を介して行われるようになりました
- パフォーマンスの最適化-Modelproxy、newbasemodelで-クエリの削減>、一部の属性はモデルにキャッシュされます
- 未使用のリレーショナルコードをクリーンアップします
- オプションのパフォーマンス依存関係orjsonを追加します(強くお勧めします)
- ドキュメントの更新
0.4.4
- sqlからフィールドを除外するために、out put_field()メソッドを追加します
- カラム名設定(エイリアス)を再構築します
- エイリアス付きの列の並べ替えを修正しました
- フィールドと除外フィールドの追加テスト
- ドキュメントの更新
0.4.3
- model. model_dump()とmodel.model_dump_json()のプロパティを含みます
0.4.2
- pydanticモデルの作成を変更して、pkのみを埋める関連モデルを返すことができるようにします
0.4.1
- 並べ替えを許可するために、クエリセットにorder_byメソッドを追加します
- ドキュメントの更新
0.4.0
- はモデル定義のシンボルを変更しました->name: ormar.Field()ではなくname=ormar.Field()を使用するようになりました
- 古い表現はまだサポートされていますが、廃止されており、mypyやpydantic pyCharmプラグインなどの静的チェッカーとうまく機能しないことに注意してください
- ヒント文書を入力してテストします
- mypyを使用してテストすることはできず、ormarパッケージのみを使用できます。
- max_digitsとdecimal_place pydantic Decimalフィールドを使用して、スケールと精度の変換を修正します
- ドキュメントの更新-依存関係を追加するためのベストプラクティス
- 型ヒントをより適切に使用するために、メタクラスとmodel_fieldをリファクタリングします
- mypyとpydanticプラグインをドキュメントに追加します
- 多対多のリレーションシップに関するドキュメントを展開します
0.3.11
- pythonでserver_defaultをデフォルトのフィールド値に設定する問題を修正
0.3.10
- 異なるバックエンドを使用しているときにドライバがインストールされていない例外を回避するために、postgresqlチェックを修正しました
0.3.9
-
19からJSONパターン生成を修正する
- ormar. Modelsのfastapiコピーで初期化されていないManyTomany関係の問題を修正しました
- fastapiの使用に関するドキュメントを更新します
- fastapi/docsが正しく生成されていることを確認するためのテストを追加
0.3.8
- 代替データベースカラム名をすべてのフィールドにnameパラメーターとともに提供する機能が追加されました。
- 関連するManyTomanyフィールドが空の場合、field()を使用して選択するエラーを修正しました。
- ドキュメントの更新
0.3.7
- ドキュメントの公開とREADMEの更新
0.3.6
- データベースで選択されているカラムを制限するためにfield()メソッドを追加します。
- UniqueColumnsと制約リストがモデル要素に追加され、カラムリストに一意の制約が構築されます。
- Char(32)カラム型に基づくUUIDフィールド型が追加されました。
0.3.5
- 複数のオブジェクトに対する操作のbulk_createとbulk_updateを追加しました。
0.3.4
クエリセットレベルメソッドの追加
- 削除する
- 更新する
- 取得または作成
- 更新または作成
0.3.3
- 追加のフィルタを追加-開始と終了
0.3.2
- すべてのフィールドにオプションパラメーターを追加-受け入れられる値を指定された値に制限します
0.3.1
- where not条件をフィルタリングするために除外が追加されました。
- mysqlとpostgresのテストを追加し、postgresを修正しました。
- Rafactorとクリーンアップ。
0.3.0
- ManyTomanyフィールドが追加され、多対多の関係がサポートされました