Open Stack

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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev