fastapi 0.30.0

on Python PyPI

Add support for Pydantic's ORM mode:

• Updated documentation about SQL with SQLAlchemy, using Pydantic models with ORM mode, SQLAlchemy models with relations, separation of files, simplification of code and other changes. New docs: SQL (Relational) Databases.
• The new support for ORM mode fixes issues/adds features related to ORMs with lazy-loading, hybrid properties, dynamic/getters (using @property decorators) and several other use cases.
• This applies to ORMs like SQLAlchemy, Peewee, Tortoise ORM, GINO ORM and virtually any other.
• If your path operations return an arbitrary object with attributes (e.g. my_item.name instead of my_item["name"]) AND you use a response_model, make sure to update the Pydantic models with orm_mode = True as described in the docs (link above).
• New documentation about receiving plain dicts as request bodies: Bodies of arbitrary dicts.
• New documentation about returning arbitrary dicts in responses: Response with arbitrary dict.
• Technical Details:
  • When declaring a response_model it is used directly to generate the response content, from whatever was returned from the path operation function.
  • Before this, the return content was first passed through jsonable_encoder to ensure it was a "jsonable" object, like a dict, instead of an arbitrary object with attributes (like an ORM model). That's why you should make sure to update your Pydantic models for objects with attributes to use orm_mode = True.
  • If you don't have a response_model, the return object will still be passed through jsonable_encoder first.
  • When a response_model is declared, the same response_model type declaration won't be used as is, it will be "cloned" to create an new one (a cloned Pydantic Field with all the submodels cloned as well).
  • This avoids/fixes a potential security issue: as the returned object is passed directly to Pydantic, if the returned object was a subclass of the response_model (e.g. you return a UserInDB that inherits from User but contains extra fields, like hashed_password, and User is used in the response_model), it would still pass the validation (because UserInDB is a subclass of User) and the object would be returned as-is, including the hashed_password. To fix this, the declared response_model is cloned, if it is a Pydantic model class (or contains Pydantic model classes in it, e.g. in a List[Item]), the Pydantic model class(es) will be a different one (the "cloned" one). So, an object that is a subclass won't simply pass the validation and returned as-is, because it is no longer a sub-class of the cloned response_model. Instead, a new Pydantic model object will be created with the contents of the returned object. So, it will be a new object (made with the data from the returned one), and will be filtered by the cloned response_model, containing only the declared fields as normally.
• PR #322.

Remove/clean unused RegEx code in routing. PR #314 by @dmontagu.

Use default response status code descriptions for additional responses. PR #313 by @duxiaoyao.

Upgrade Pydantic support to 0.28. PR #320 by @jekirl.