Open Stack

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-request at 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-request at 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.