* WIP * WIP - make test_model_definition tests pass * WIP - make test_model_methods pass * WIP - make whole test suit at least run - failing 49/443 tests * WIP fix part of the getting pydantic tests as types of fields are now kept in core schema and not on fieldsinfo * WIP fix validation in update by creating individual fields validators, failing 36/443 * WIP fix __pydantic_extra__ in intializing model, fix test related to pydantic config checks, failing 32/442 * WIP - fix enum schema in model_json_schema, failing 31/442 * WIP - fix copying through model, fix setting pydantic fields on through, fix default config and inheriting from it, failing 26/442 * WIP fix tests checking pydantic schema, fix excluding parent fields, failing 21/442 * WIP some missed files * WIP - fix validators inheritance and fix validators in generated pydantic, failing 17/442 * WIP - fix through models setting - only on reverse side of relation, but always on reverse side, failing 15/442 * WIP - fix through models setting - only on reverse side of relation, but always on reverse side, failing 15/442 * WIP - working on proper populating __dict__ for relations for new schema dumping, some work on openapi docs, failing 13/442 * WIP - remove property fields as pydantic has now computed_field on its own, failing 9/442 * WIP - fixes in docs, failing 8/442 * WIP - fix tests for largebinary schema, wrapped bytes fields fail in pydantic, will be fixed in pydantic-core, remaining is circural schema for related models, failing 6/442 * WIP - fix to pk only models in schemas * Getting test suites to pass (#1249) * wip, fixing tests * iteration, fixing some more tests * iteration, fixing some more tests * adhere to comments * adhere to comments * remove unnecessary dict call, re-add getattribute for testing * todo for reverse relationship * adhere to comments, remove prints * solve circular refs * all tests pass 🎉 * remove 3.7 from tests * add lint and type check jobs * reforat with ruff, fix jobs * rename jobs * fix imports * fix evaluate in py3.8 * partially fix coverage * fix coverage, add more tests * fix test ids * fix test ids * fix lint, fix docs, make docs fully working scripts, add test docs job * fix pyproject * pin py ver in test docs * change dir in test docs * fix pydantic warning hack * rm poetry call in test_docs * switch to pathlib in test docs * remove coverage req test docs * fix type check tests, fix part of types * fix/skip next part of types * fix next part of types * fix next part of types * fix coverage * fix coverage * fix type (bit dirty 🤷) * fix some code smells * change pre-commit * tweak workflows * remove no root from tests * switch to full python path by passing sys.executable * some small refactor in new base model, one sample test, change makefile * small refactors to reduce complexity of methods * temp add tests for prs against pydantic_v2 * remove all references to __fields__ * remove all references to construct, deprecate the method and update model_construct to be in line with pydantic * deprecate dict and add model_dump, todo switch to model_dict in calls * fix tests * change to union * change to union * change to model_dump and model_dump_json from dict and json deprecated methods, deprecate them in ormar too * finish switching dict() -> model_dump() * finish switching json() -> model_dump_json() * remove fully pydantic_only * switch to extra for payment card, change missed json calls * fix coverage - no more warnings internal * fix coverage - no more warnings internal - part 2 * split model_construct into own and pydantic parts * split determine pydantic field type * change to new field validators * fix benchmarks, add codspeed instead of pytest-benchmark, add action and gh workflow * restore pytest-benchmark * remove codspeed * pin pydantic version, restore codspeed * change on push to pydantic_v2 to trigger first one * Use lifespan function instead of event (#1259) * check return types * fix imports order, set warnings=False on json that passes the dict, fix unnecessary loop in one of the test * remove references to model's meta as it's now ormar config, rename related methods too * filter out pydantic serializer warnings * remove choices leftovers * remove leftovers after property_fields, keep only enough to exclude them in initialization * add migration guide * fix meta references * downgrade databases for now * Change line numbers in documentation (#1265) * proofread and fix the docs, part 1 * proofread and fix the docs for models * proofread and fix the docs for fields * proofread and fix the docs for relations * proofread and fix rest of the docs, add release notes for 0.20 * create tables in new docs src * cleanup old deps, uncomment docs publish on tag * fix import reorder --------- Co-authored-by: TouwaStar <30479449+TouwaStar@users.noreply.github.com> Co-authored-by: Goran Mekić <meka@tilda.center>
9.7 KiB
ForeignKey
ForeignKey(to: Model, *, name: str = None, unique: bool = False, nullable: bool = True, related_name: str = None, virtual: bool = False, onupdate: Union[ReferentialAction, str] = None, ondelete: Union[ReferentialAction, str] = None, **kwargs: Any)
has required parameters to that takes target Model class.
Sqlalchemy column and Type are automatically taken from target Model.
- Sqlalchemy column: class of a target
Modelprimary key column - Type (used for pydantic): type of a target
Model
Defining Models
To define a relation add ForeignKey field that points to related Model.
--8<-- "../docs_src/fields/docs003.py"
Reverse Relation
ForeignKey fields are automatically registering reverse side of the relation.
By default it's child (source) Model name + s, like courses in snippet below:
--8<-- "../docs_src/fields/docs001.py"
Reverse relation exposes API to manage related objects also from parent side.
Skipping reverse relation
If you are sure you don't want the reverse relation you can use skip_reverse=True
flag of the ForeignKey.
If you set skip_reverse flag internally the field is still registered on the other
side of the relationship so you can:
filterby related models fields from reverse modelorder_byby related models fields from reverse model
But you cannot:
- Access the related field from reverse model with
related_name - Even if you
select_relatedfrom reverse side of the model the returned models won't be populated in reversed instance (the join is not prevented so you still canfilterandorder_byover the relation) - The relation won't be populated in
model_dump()andmodel_dump_json() - You cannot pass the nested related objects when populating from dictionary or json (also through
fastapi). It will be either ignored or error will be raised depending onextrasetting in pydanticConfig.
Example:
class Author(ormar.Model):
ormar_config = base_ormar_config.copy()
id: int = ormar.Integer(primary_key=True)
first_name: str = ormar.String(max_length=80)
last_name: str = ormar.String(max_length=80)
class Post(ormar.Model):
ormar_config = base_ormar_config.copy()
id: int = ormar.Integer(primary_key=True)
title: str = ormar.String(max_length=200)
author: Optional[Author] = ormar.ForeignKey(Author, skip_reverse=True)
# create sample data
author = Author(first_name="Test", last_name="Author")
post = Post(title="Test Post", author=author)
assert post.author == author # ok
assert author.posts # Attribute error!
# but still can use in order_by
authors = (
await Author.objects.select_related("posts").order_by("posts__title").all()
)
assert authors[0].first_name == "Test"
# note that posts are not populated for author even if explicitly
# included in select_related - note no posts in model_dump()
assert author.model_dump(exclude={"id"}) == {"first_name": "Test", "last_name": "Author"}
# still can filter through fields of related model
authors = await Author.objects.filter(posts__title="Test Post").all()
assert authors[0].first_name == "Test"
assert len(authors) == 1
add
Adding child model from parent side causes adding related model to currently loaded parent relation, as well as sets child's model foreign key value and updates the model.
department = await Department(name="Science").save()
course = Course(name="Math", completed=False) # note - not saved
await department.courses.add(course)
assert course.pk is not None # child model was saved
# relation on child model is set and FK column saved in db
assert course.department == department
# relation on parent model is also set
assert department.courses[0] == course
!!!warning If you want to add child model on related model the primary key value for parent model has to exist in database.
Otherwise ormar will raise `RelationshipInstanceError` as it cannot set child's ForeignKey column value
if parent model has no primary key value.
That means that in example above the department has to be saved before you can call `department.courses.add()`.
!!!warning
This method will not work on ManyToMany relations - there, both sides of the relation have to be saved before adding to relation.
remove
Removal of the related model one by one.
In reverse relation calling remove() does not remove the child model, but instead nulls it ForeignKey value.
# continuing from above
await department.courses.remove(course)
assert len(department.courses) == 0
# course still exists and was saved in remove
assert course.pk is not None
assert course.department is None
# to remove child from db
await course.delete()
But if you want to clear the relation and delete the child at the same time you can issue:
# this will not only clear the relation
# but also delete related course from db
await department.courses.remove(course, keep_reversed=False)
clear
Removal of all related models in one call.
Like with remove, by default, clear() nulls the ForeigKey column on child model (all, not matter if they are loaded or not).
# nulls department column on all courses related to this department
await department.courses.clear()
If you want to remove the children altogether from the database, set keep_reversed=False
# deletes from db all courses related to this department
await department.courses.clear(keep_reversed=False)
QuerysetProxy
Reverse relation exposes QuerysetProxy API that allows you to query related model like you would issue a normal Query.
To read which methods of QuerySet are available read below querysetproxy
related_name
You can overwrite related model field name by providing related_name parameter like below:
--8<-- "../docs_src/fields/docs002.py"
!!!tip
The reverse relation on access returns list of wekref.proxy to avoid circular references.
!!!warning
When you provide multiple relations to the same model ormar can no longer auto generate
the related_name for you. Therefore, in that situation you have to provide related_name
for all but one (one can be default and generated) or all related fields.
Referential Actions
When an object referenced by a ForeignKey is changed (deleted or updated),
ormar will set the SQL constraint specified by the ondelete and onupdate argument.
The possible values for ondelete and onupdate are found in ormar.ReferentialAction:
!!!note
Instead of ormar.ReferentialAction, you can directly pass string values to these two arguments, but this is not recommended because it will break the integrity.
CASCADE
Whenever rows in the parent (referenced) table are deleted (or updated), the respective rows of the child (referencing) table with a matching foreign key column will be deleted (or updated) as well. This is called a cascade delete (or update).
RESTRICT
A value cannot be updated or deleted when a row exists in a referencing or child table that references the value in the referenced table.
Similarly, a row cannot be deleted as long as there is a reference to it from a referencing or child table.
SET_NULL
Set the ForeignKey to None; this is only possible if nullable is True.
SET_DEFAULT
Set the ForeignKey to its default value; a server_default for the ForeignKey must be set.
!!!note
Note that the default value is not allowed and you must do this through server_default, which you can read about in this section.
DO_NOTHING
Take NO ACTION; NO ACTION and RESTRICT are very much alike. The main difference between NO ACTION and RESTRICT is that with NO ACTION the referential integrity check is done after trying to alter the table. RESTRICT does the check before trying to execute the UPDATE or DELETE statement. Both referential actions act the same if the referential integrity check fails: the UPDATE or DELETE statement will result in an error.
Relation Setup
You have several ways to set-up a relationship connection.
Model instance
The most obvious one is to pass a related Model instance to the constructor.
--8<-- "../docs_src/relations/docs001.py"
Primary key value
You can setup the relation also with just the pk column value of the related model.
--8<-- "../docs_src/relations/docs001.py"
Dictionary
Next option is with a dictionary of key-values of the related model.
You can build the dictionary yourself or get it from existing model with model_dump() method.
--8<-- "../docs_src/relations/docs001.py"
None
Finally you can explicitly set it to None (default behavior if no value passed).
--8<-- "../docs_src/relations/docs001.py"
!!!warning In all not None cases the primary key value for related model has to exist in database.
Otherwise an IntegrityError will be raised by your database driver library.