* 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>
194 lines
6.1 KiB
Markdown
194 lines
6.1 KiB
Markdown
# Migrations
|
|
|
|
## Database Initialization
|
|
|
|
Note that all examples assume that you already have a database.
|
|
|
|
If that is not the case and you need to create your tables, that's super easy as `ormar` is using sqlalchemy for underlying table construction.
|
|
|
|
All you have to do is call `create_all()` like in the example below.
|
|
|
|
```python
|
|
import sqlalchemy
|
|
# get your database url in sqlalchemy format - same as used with databases instance used in Model definition
|
|
engine = sqlalchemy.create_engine("sqlite:///test.db")
|
|
# note that this has to be the same metadata that is used in ormar Models definition
|
|
metadata.create_all(engine)
|
|
```
|
|
|
|
You can also create single tables, sqlalchemy tables are exposed in `ormar.ormar_config` object.
|
|
|
|
```python
|
|
import sqlalchemy
|
|
# get your database url in sqlalchemy format - same as used with databases instance used in Model definition
|
|
engine = sqlalchemy.create_engine("sqlite:///test.db")
|
|
# Artist is an ormar model from previous examples
|
|
Artist.ormar_config.table.create(engine)
|
|
```
|
|
|
|
!!!warning
|
|
You need to create the tables only once, so use a python console for that or remove the script from your production code after first use.
|
|
|
|
|
|
## Alembic usage
|
|
|
|
Likewise as with tables, since we base tables on sqlalchemy for migrations please use [alembic][alembic].
|
|
|
|
### Initialization
|
|
|
|
Use command line to reproduce this minimalistic example.
|
|
|
|
```python
|
|
alembic init alembic
|
|
alembic revision --autogenerate -m "made some changes"
|
|
alembic upgrade head
|
|
```
|
|
|
|
### Sample env.py file
|
|
|
|
A quick example of alembic migrations should be something similar to:
|
|
|
|
When you have application structure like:
|
|
|
|
```
|
|
-> app
|
|
-> alembic (initialized folder - so run alembic init alembic inside app folder)
|
|
-> models (here are the models)
|
|
-> __init__.py
|
|
-> my_models.py
|
|
```
|
|
|
|
Your `env.py` file (in alembic folder) can look something like:
|
|
|
|
```python
|
|
from logging.config import fileConfig
|
|
from sqlalchemy import create_engine
|
|
|
|
from alembic import context
|
|
import sys, os
|
|
|
|
# add app folder to system path (alternative is running it from parent folder with python -m ...)
|
|
myPath = os.path.dirname(os.path.abspath(__file__))
|
|
sys.path.insert(0, myPath + '/../../')
|
|
|
|
# this is the Alembic Config object, which provides
|
|
# access to the values within the .ini file in use.
|
|
config = context.config
|
|
|
|
# Interpret the config file for Python logging.
|
|
# This line sets up loggers basically.
|
|
fileConfig(config.config_file_name)
|
|
|
|
# add your model's MetaData object here (the one used in ormar)
|
|
# for 'autogenerate' support
|
|
from app.models.my_models import metadata
|
|
target_metadata = metadata
|
|
|
|
|
|
# set your url here or import from settings
|
|
# note that by default url is in saved sqlachemy.url variable in alembic.ini file
|
|
URL = "sqlite:///test.db"
|
|
|
|
|
|
def run_migrations_offline():
|
|
"""Run migrations in 'offline' mode.
|
|
|
|
This configures the context with just a URL
|
|
and not an Engine, though an Engine is acceptable
|
|
here as well. By skipping the Engine creation
|
|
we don't even need a DBAPI to be available.
|
|
|
|
Calls to context.execute() here emit the given string to the
|
|
script output.
|
|
|
|
"""
|
|
context.configure(
|
|
url=URL,
|
|
target_metadata=target_metadata,
|
|
literal_binds=True,
|
|
dialect_opts={"paramstyle": "named"},
|
|
# if you use UUID field set also this param
|
|
# the prefix has to match sqlalchemy import name in alembic
|
|
# that can be set by sqlalchemy_module_prefix option (default 'sa.')
|
|
user_module_prefix='sa.'
|
|
)
|
|
|
|
with context.begin_transaction():
|
|
context.run_migrations()
|
|
|
|
|
|
def run_migrations_online():
|
|
"""Run migrations in 'online' mode.
|
|
|
|
In this scenario we need to create an Engine
|
|
and associate a connection with the context.
|
|
|
|
"""
|
|
connectable = create_engine(URL)
|
|
|
|
with connectable.connect() as connection:
|
|
context.configure(
|
|
connection=connection,
|
|
target_metadata=target_metadata,
|
|
# if you use UUID field set also this param
|
|
# the prefix has to match sqlalchemy import name in alembic
|
|
# that can be set by sqlalchemy_module_prefix option (default 'sa.')
|
|
user_module_prefix='sa.'
|
|
)
|
|
|
|
with context.begin_transaction():
|
|
context.run_migrations()
|
|
|
|
|
|
if context.is_offline_mode():
|
|
run_migrations_offline()
|
|
else:
|
|
run_migrations_online()
|
|
|
|
```
|
|
|
|
### Excluding tables
|
|
|
|
You can also include/exclude specific tables with `include_object` parameter passed to `context.configure`. That should be a function returning `True/False` for given objects.
|
|
|
|
A sample function excluding tables starting with `data_` in name unless it's 'data_jobs':
|
|
```python
|
|
def include_object(object, name, type_, reflected, compare_to):
|
|
if name and name.startswith('data_') and name not in ['data_jobs']:
|
|
return False
|
|
|
|
return True
|
|
```
|
|
|
|
!!!note
|
|
Function parameters for `include_objects` (you can change the name) are required and defined in alembic
|
|
to check what they do check the [alembic][alembic] documentation
|
|
|
|
And you pass it into context like (both in online and offline):
|
|
```python
|
|
context.configure(
|
|
url=URL,
|
|
target_metadata=target_metadata,
|
|
literal_binds=True,
|
|
dialect_opts={"paramstyle": "named"},
|
|
user_module_prefix='sa.',
|
|
include_object=include_object
|
|
)
|
|
```
|
|
|
|
!!!info
|
|
You can read more about table creation, altering and migrations in [sqlalchemy table creation][sqlalchemy table creation] documentation.
|
|
|
|
[fields]: ./fields.md
|
|
[relations]: ./relations/index.md
|
|
[queries]: ./queries.md
|
|
[pydantic]: https://pydantic-docs.helpmanual.io/
|
|
[sqlalchemy-core]: https://docs.sqlalchemy.org/en/latest/core/
|
|
[sqlalchemy-metadata]: https://docs.sqlalchemy.org/en/13/core/metadata.html
|
|
[databases]: https://github.com/encode/databases
|
|
[sqlalchemy connection string]: https://docs.sqlalchemy.org/en/13/core/engines.html#database-urls
|
|
[sqlalchemy table creation]: https://docs.sqlalchemy.org/en/13/core/metadata.html#creating-and-dropping-database-tables
|
|
[alembic]: https://alembic.sqlalchemy.org/en/latest/tutorial.html
|
|
[save status]: ../models/index/#model-save-status
|
|
[Internals]: #internals
|