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
