Re: [openstack-dev] [Murano] SQLite support - drop or not?

2015-02-06 Thread Adam Young
Drop. It is wasting cycles, and not something we should use in production. Migrations specific to SQLPlus are the most time consuming work-arounds we have. SQLPlus does not suit our development approach. On 02/03/2015 01:32 PM, Georgy Okrokvertskhov wrote: I think we should switch to clean

Re: [openstack-dev] [Murano] SQLite support - drop or not?

2015-02-03 Thread Georgy Okrokvertskhov
I think we should switch to clean migration path. We do have production installations but we can handle initial db uprgade case by case for customers. It is better to fix this issue now when we have few customers rather then doing later at larger scale. Thanks Georgy On Tue, Feb 3, 2015 at 9:05 A

Re: [openstack-dev] [Murano] SQLite support - drop or not?

2015-02-03 Thread Mike Bayer
Andrew Pashkin wrote: > Mike Bayer wrote: >> there’s always a naming convention in place; all databases other than >> SQLite produce them on the fly if you don’t specify one. The purpose >> of the Alembic/SQLAlchemy naming_convention feature is so that you >> have *one* naming convention, rath

Re: [openstack-dev] [Murano] SQLite support - drop or not?

2015-02-03 Thread Andrew Pashkin
Mike Bayer wrote: > there’s always a naming convention in place; all databases other than > SQLite produce them on the fly if you don’t specify one. The purpose > of the Alembic/SQLAlchemy naming_convention feature is so that you > have *one* naming convention, rather than N unpredictable conventi

Re: [openstack-dev] [Murano] SQLite support - drop or not?

2015-02-03 Thread Mike Bayer
Andrew Pashkin wrote: > Mike Bayer wrote: >> The patch seems to hardcode the conventions for MySQL and Postgresql. >> The first thought I had was that in order to remove the dependence >> on them here, you’d need to instead simply turn off the >> “naming_convention” in the MetaData if you detec

Re: [openstack-dev] [Murano] SQLite support - drop or not?

2015-02-03 Thread Andrew Pashkin
Mike Bayer wrote: > The patch seems to hardcode the conventions for MySQL and Postgresql. > The first thought I had was that in order to remove the dependence > on them here, you’d need to instead simply turn off the > “naming_convention” in the MetaData if you detect that you’re on one > of those

Re: [openstack-dev] [Murano] SQLite support - drop or not?

2015-01-30 Thread Mike Bayer
Andrew Pashkin wrote: > Working on this issue I encountered another problem. > > Most indices in the project has no names and because of that, > developer must reverse-engineer them in every migration. > Read about that also here [1]. > > SQLAlchemy and Alembic provide feature for generation

Re: [openstack-dev] [Murano] SQLite support - drop or not?

2015-01-30 Thread Andrew Pashkin
Working on this issue I encountered another problem. Most indices in the project has no names and because of that, developer must reverse-engineer them in every migration. Read about that also here [1]. SQLAlchemy and Alembic provide feature for generation constraint names by pattern, specificall

Re: [openstack-dev] [Murano] SQLite support - drop or not?

2015-01-27 Thread Andrew Pashkin
On 26.01.2015 18:34, Ruslan Kamaldinov wrote: > On Mon, Jan 26, 2015 at 6:12 PM, Andrew Pashkin wrote: >> On 26.01.2015 18:05, Ruslan Kamaldinov wrote: >> >> I think it's still important to perform migration specific checks. We want >> to make sure that DB is in expected state after each specific

Re: [openstack-dev] [Murano] SQLite support - drop or not?

2015-01-26 Thread Ruslan Kamaldinov
On Mon, Jan 26, 2015 at 6:12 PM, Andrew Pashkin wrote: > On 26.01.2015 18:05, Ruslan Kamaldinov wrote: > > I think it's still important to perform migration specific checks. We want > to make sure that DB is in expected state after each specific migration. > > Why? 1. It's not just the schema we

Re: [openstack-dev] [Murano] SQLite support - drop or not?

2015-01-26 Thread Andrew Pashkin
/On 26.01.2015 18:05, Ruslan Kamaldinov wrote:/ /I think it's still important to perform migration specific checks. We want to make sure that DB is in expected state after each specific migration./ Why? On 26.01.2015 18:05, Ruslan Kamaldinov wrote: On Mon, Jan 26, 2015 at 3:03 PM, Andrew Pash

Re: [openstack-dev] [Murano] SQLite support - drop or not?

2015-01-26 Thread Ruslan Kamaldinov
On Mon, Jan 26, 2015 at 3:03 PM, Andrew Pashkin wrote: > 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 un

Re: [openstack-dev] [Murano] SQLite support - drop or not?

2015-01-26 Thread Andrew Pashkin
/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

Re: [openstack-dev] [Murano] SQLite support - drop or not?

2015-01-23 Thread Ruslan Kamaldinov
On Fri, Jan 23, 2015 at 9:04 PM, Andrew Pashkin wrote: > Hello! > > Current situation with SQLite support: > - Migration tests does not run on SQLIte. > - At the same time migrations themselves support SQLite (with bugs). > > Today I came across this bug: > Error during execution of database downg

Re: [openstack-dev] [Murano] SQLite support - drop or not?

2015-01-23 Thread Georgy Okrokvertskhov
Hi Andrew, I understand the difficulties with SQLite support, but this is very useful for development to have SQLite instead of any other DB. I think nodoby uses SQLite in production, so probably we can just put a release note that there is a know limitation with SQLite support. Thanks Gosha On

[openstack-dev] [Murano] SQLite support - drop or not?

2015-01-23 Thread Andrew Pashkin
Hello! Current situation with SQLite support: - Migration tests does not run on SQLIte. - At the same time migrations themselves support SQLite (with bugs). Today I came across this bug: Error during execution of database downgrade We can resol