On Tue, Aug 27, 2013 at 12:30 PM, Jay Pipes wrote:
> On 08/27/2013 04:32 AM, Boris Pavlovic wrote:
>
>> Jay,
>>
>> I should probably share to you about our work around DB.
>>
>> Migrations should be run only in production and only for production
>> backends (e.g. psql and mysql)
>> In tests we sh
Hi,
Instead of spending tons of times through these mailing lists lets make a
code and reviews:
There is already RoadMap about what we should do.
1. Sync DB.Models with result of migrations
2. Sync migrations for different backends
3. (OSLO) Merge checker that all is synced in
https://review.ope
Hello,
Please see my answers inline and my previous email regarding this topic:
Hello,
This conversion is actually quite simple. We are currently working to
support alembic migrations in ceilometer:
https://blueprints.launchpad.net/ceilometer/+spec/convert-to-alembic
For now we agreed that c
Jay,
We are not able to use in this approach in moment because we don't have
> any mechanism to check that MODELS and SCHEMAS are EQUAL.
> And actually MODELS and SCHEMAS are DIFFERENT.
>
Sorry, I don't understand the connection... how does not having a codified
way of determining the differenc
On 08/27/2013 04:32 AM, Boris Pavlovic wrote:
Jay,
I should probably share to you about our work around DB.
Migrations should be run only in production and only for production
backends (e.g. psql and mysql)
In tests we should use Schemas created by Models
(BASE.metadata.create_all())
Agree on
On 08/27/2013 11:22 AM, Sandy Walsh wrote:
On 08/27/2013 05:32 AM, Boris Pavlovic wrote:
Jay,
I should probably share to you about our work around DB.
Migrations should be run only in production and only for production
backends (e.g. psql and mysql)
In tests we should use Schemas created by Mo
On 08/27/2013 05:32 AM, Boris Pavlovic wrote:
> Jay,
>
> I should probably share to you about our work around DB.
>
> Migrations should be run only in production and only for production
> backends (e.g. psql and mysql)
> In tests we should use Schemas created by Models
> (BASE.metadata.create
Jay,
I should probably share to you about our work around DB.
Migrations should be run only in production and only for production
backends (e.g. psql and mysql)
In tests we should use Schemas created by Models
(BASE.metadata.create_all())
We are not able to use in this approach in moment becaus
On 08/26/2013 03:40 PM, Herndon, John Luke (HPCS - Ft. Collins) wrote:
Jay -
It looks there is an error in the migration script that causes it to abort:
AttributeError: 'ForeignKeyConstraint' object has no attribute 'drop'
My guess is the migration runs on the first test, creates event types
t
Jay -
It looks there is an error in the migration script that causes it to abort:
AttributeError: 'ForeignKeyConstraint' object has no attribute 'drop'
My guess is the migration runs on the first test, creates event types
table fine, but exits with the above error, so migration is not
"complete
On 08/26/2013 03:27 PM, Monsyne Dragon wrote:
You should be able to get the dialect_name from the context in the alembic
migration and do something like:
if dialect_name == 'sqlite':
#Do whacky sqlite stuff hereŠ
else:
#sane db migration hère...
Hmm, ok, thanks for the su
You should be able to get the dialect_name from the context in the alembic
migration and do something like:
if dialect_name == 'sqlite':
#Do whacky sqlite stuff hereŠ
else:
#sane db migration hère...
On 8/26/13 1:59 PM, "Sandy Walsh" wrote:
>I'm getting the same problem wit
I just noticed that every single test case for SQL-driver storage is
executing every single migration upgrade before every single test case run:
https://github.com/openstack/ceilometer/blob/master/ceilometer/tests/db.py#L46
https://github.com/openstack/ceilometer/blob/master/ceilometer/storage/
I'm getting the same problem with a different migration (mine is
complaining that a column already exists)
http://paste.openstack.org/show/44512/
I've compared it to the other migrations and it seems fine.
-S
On 08/26/2013 02:34 PM, Jay Pipes wrote:
> Hey all,
>
> I'm trying to figure out what
14 matches
Mail list logo