On 18-Apr-15 02:41, Mike Bayer wrote: > > > On 4/17/15 1:29 PM, Zane Bitter wrote: >> On 16/04/15 04:05, Anant Patil wrote: >>> Hi, >>> >>> Sometime back we had a discussion on IRC regarding sqlite migration >>> scripts. Since sqlite is mostly used for testing, we were thinking >>> about moving the sqlite migration related code to tests folder and >>> keep the migrate_repo sane (with only production code). There was >>> utility class[1] added recently for helping with sqlite migrations >>> and there were questions on the location of that class. The utility >>> lives in heat/db/sqlalchemy folder and since it is used only for >>> testing, it should probably live somewhere in the tests folder (like >>> tests/migrate_repo? ) along with the sqlite migration scripts. >>> >>> It would be better if we have a separate path for testing code and >>> depending on the configured DB back-end (for example, sqlite), we pass >>> the appropriate path (something like tests/migrate_repo for sqlite) to >>> oslo_migration.db_sync(). >>> >>> If it is okay to assume that sqlite is *always* used for testing, then >>> IMO, we should re-factor the migration scripts. Please help us with your >>> thoughts. >>> >>> [1] >>> https://github.com/openstack/heat/blob/master/heat/db/sqlalchemy/utils.py >>> >>> >>> - Anant >> >> You're correct that we can assume SQLite is only used for tests. >> >> However, I'm not convinced that we need to change the migration >> scripts... it's bad enough that we have to write two different >> migrations in many cases (and totally unclear to me how this is >> testing anything useful), but having to write them in two different >> places seems even worse. >> >> I'd be more interested in seeing a change whereby we stop doing >> pointless migrations on an empty SQLite DB prior to testing and just >> generate it from the model. I think we can rely on the migration tests >> that run against the actual mariadb/postgresql clients to test the >> migrations themselves - we effectively already are in many cases. > > We definitely should be generating to SQLite from the model directly for > all projects without using migrations. I'm going to be pushing more > for migrating projects from sqlalchemy-migrate to alembic, and while > Alembic does do SQLite migrations now, it would be cleaner if we just > didn't bother. > > There are also new features in the oslo.db test base that can allow a > schema to be created only once for lots of tests, where the tests > themselves run under a transaction that's rolled back during teardown; > the table structures stay in place. We should be looking to use that > base for most/all of our DB-active tests. > > > > > > >> >> cheers, >> Zane. >> >> __________________________________________________________________________ >> >> 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 > > > __________________________________________________________________________ > 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 >
+1 for moving to Alembic as it abstracts out the migration logic, and that will help Heat have a cleaner code base for migrations. __________________________________________________________________________ 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
