-
Notifications
You must be signed in to change notification settings - Fork 957
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
chapter2: How to use alembic for migrations for sqlalchemy classical mapper? #14
Comments
we usually define all our tables in a file called here's an example db_tables.py from a real project: from sqlalchemy import (
Table, MetaData, Column, Integer, String, ForeignKey, UniqueConstraint,
)
from sqlalchemy.dialects.postgresql import JSONB
metadata = MetaData()
orders = Table(
'order_placed', metadata,
Column('surrogate_id', Integer, primary_key=True, autoincrement=True, nullable=False),
Column('order_id', String(255), unique=True, index=True, nullable=False),
Column('order_placement_time', String(255), nullable=False),
Column('promised_before_date', String(255), nullable=True),
Column('currency_code', String(255), nullable=False),
... and here's the alembic config, which i think alembic by default expects you to put into a file called from alembic import context
from ourproject import db_tables
# this is the Alembic Config object, which provides
# access to the values within the .ini file in use.
config = context.config
# add your model's MetaData object here
# for 'autogenerate' support
# from myapp import mymodel
# target_metadata = mymodel.Base.metadata
target_metadata = db_tables.metadata
... and that's about all you need, alembic let me know if there's anything else I can do to help! (note to self: put this in a blog post. or appendix) |
got it, the point is 'target_metadata'. Thanks for the quick reply. |
I read more discussions before more testing, it seems a little risky for widely use in product: |
i should probably post a reply on that sqla thread. but we've not found any problems operationally with classical mappers, and it's been about 5 years now. admittedly we don't use dataclasses much in our domain model classes. incidentally, you can use sqlalchemy + alembic purely for schema declarations and migrations, and then not use the ORM at all. I've built one project like that, and we're quite happy with it. The repository just uses raw SQL. but we still have a |
yes me too, I didn't use dataclasses and attrs much, trying to explore some way to make domain model class with less limitations in syntax. (I saw you've written some classes Inherited from dict in some branch, another try?) For example:
if I create biz model such as user, I need to take care of the fields' default value:
For me, it seems a little bit confused to choose a perfect way to handle domain model in python, other than stuffs like JPA in java world. |
hmmm. well one way to keep life simple would be to not use dataclasses for Entities, only Value Objects? just use plain python objects for your entities, then inheritance, and the interactions with sqlalchemy will both be more predictable... |
Just had time to make up codes months ago.
|
Thanks to the very first and nice book for python developer to practice ddd. I have detailed questions when doing real project practice, one of those is:
We use sqlalchemy model and flask-migrate (based on alembic), at most of our projects. The work flow
about db seems like: 'flask db init' --> 'flask db migrate' --> 'flask db upgrade' --> ...
All the 'models'(sa model but not domain model) can be detected by alembic, so does the changing of the 'models'.
So if change to classical mapper, I'm not sure is there an easy way to change the workflow, or may be you already have some working code or build command example can be shown? Thanks.
The text was updated successfully, but these errors were encountered: