On Mon, Jan 26, 2015 at 3:03 PM, Andrew Pashkin <apash...@mirantis.com> wrote: > On 23.01.2015 23:39, Ruslan Kamaldinov wrote: > > 1. Use ModelsMigrationsSync from  in tests to make sure that SQLAlchemy > models are in sync with migrations. Usage example can be found at  > > Seems like it is a great helper, as I understand it runs all migrations and > then compares DB state with models state and throws an error if they are out > of sync. > What I don't understand - why they still manually write checks for every > migration ? This is redundant, because ModelsMigrationsSync already does > the job testing that DB is in sync with models. > > By the way in Heat project they do the same thing . What am I missing?
I think it's still important to perform migration specific checks. We want to make sure that DB is in expected state after each specific migration. >  > http://git.openstack.org/cgit/openstack/sahara/tree/sahara/tests/unit/db/migration/test_migrations.py#n402 >  > https://github.com/openstack/heat/blob/7d4c4030c591ef5994db4327d66d353ad83c6ea8/heat/tests/db/test_migrations.py#L288 > 2. Populate DB schema from SQLAlchemy models in unit-tests which require > access to DB > > You mean - using these tools ? > >  > http://docs.sqlalchemy.org/en/rel_0_9/core/metadata.html#creating-and-dropping-database-tables Yes, this one. We still have this code in source tree: http://git.openstack.org/cgit/stackforge/murano/tree/murano/db/models.py#n289 > In what conditions 5) will fail? I see only these cases: > - If data migrations would be introduced and Murano would require some data > in DB to work correctly. Actually, we already do that. We populate initial set of categories: http://git.openstack.org/cgit/stackforge/murano/tree/murano/db/migration/alembic_migrations/versions/001_inital_version.py#n40 Would it affect anyone? I don't think so. You always can populate these categories manually. > - If Murano would use some database-specific features (stored procedures > etc). That should never happen :) > There are good chances that these cases will never happen in reality, as I > understand, so I tend to agree. Agree -- Ruslan __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev