/On 23.01.2015 23:39, Ruslan Kamaldinov wrote://
///
/1. Use ModelsMigrationsSync from [2] in tests to make sure that
SQLAlchemy models are in sync with migrations. Usage example can be
found at [3]/
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 [1]? 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 [2]. What am I missing?
[1]
http://git.openstack.org/cgit/openstack/sahara/tree/sahara/tests/unit/db/migration/test_migrations.py#n402
[2]
https://github.com/openstack/heat/blob/7d4c4030c591ef5994db4327d66d353ad83c6ea8/heat/tests/db/test_migrations.py#L288
/On 23.01.2015 23:39, Ruslan Kamaldinov wrote://
/
/2. Populate DB schema from SQLAlchemy models in unit-tests which
require access to DB/
You mean - using these tools [3]?
[3]
http://docs.sqlalchemy.org/en/rel_0_9/core/metadata.html#creating-and-dropping-database-tables
/On 23.01.2015 23:39, Ruslan Kamaldinov wrote://
/
/3. Wipe out everything related to SQLite from DB migrations code //
//4. Recommend all developers to use MySQL when they run Murano locally //
//5. For those who still insist on SQLite we can provide a command
line option which would generate database schema from SQLAlchemy
metadata. This should be declared as development only feature, not
supported for any kind of production deployments /
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.
- If Murano would use some database-specific features (stored procedures
etc).
There are good chances that these cases will never happen in reality, as
I understand, so I tend to agree.
--
With kind regards, Andrew Pashkin.
cell phone - +7 (985) 898 57 59
Skype - waves_in_fluids
e-mail - apash...@mirantis.com
__________________________________________________________________________
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
