From: | Dave Page <dpage(at)pgadmin(dot)org> |
---|---|
To: | Surinder Kumar <surinder(dot)kumar(at)enterprisedb(dot)com> |
Cc: | pgadmin-hackers <pgadmin-hackers(at)postgresql(dot)org> |
Subject: | Re: Next release |
Date: | 2017-08-24 16:14:35 |
Message-ID: | CA+OCxoxAFT3pbPWd-BgzyckstBccQwG3g7J0t7BKEo-5i4qzqg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgadmin-hackers |
On Thu, Aug 24, 2017 at 10:36 AM, Surinder Kumar <
surinder(dot)kumar(at)enterprisedb(dot)com> wrote:
> Hi Dave,
>
> On Thu, Aug 24, 2017 at 2:28 PM, Dave Page <dpage(at)pgadmin(dot)org> wrote:
>
>> Anyone object to doing a release on 14th September, wrapping the code on
>> Monday 11th? This seems like the best option for our QA folks who will be
>> off for EID somewhen in the two weeks before.
>>
>> Assuming not, should this be 1.7 or 2.0?
>>
>> If we go with 2.0, it'll be for "safety" given the proposed changes to
>> path management to allow both server and desktop modes to work out of the
>> box on Linux.
>>
>> If we do that, we also need to ensure that any changes to the config
>> database are backwards compatible, as a 2.0 release would be a side-by-side
>> installation. Surinder; was it you that had looked into that?
>>
> I had looked into this and here are my findings:
> 1. If we are using newer version of pgAdmin and the go back to older
> version of pgAdmin, then on running `python pgAdmin4.py`. the
> flask-migrate(Alembic) try to perform downgrade by one step only(ie. it can
> switch back to one migration only when we run `python pgAdmin4.py`). But
> we have multiple database revisions to be migrated. So migration fails here.
>
> 2. When Alebmic downgrade is performed by one step, it looks for downgrade
> function in that specific database revision, but in our code we didn't
> written downgrade function. But if we have written downgrade statement,
> still there is an issue:
> ie. If we add a new column to a table xyz using ALTER statement like:
>
> ```
>
> def upgrade():
>
> verison = get_version()
>
>
> db.engine.execute(
>
> 'ALTER TABLE server ADD COLUMN hostaddr TEXT(1024)'
>
> )
>
> def downgrade():
>
> pass
> ```
> then on downgrade it executes `downgrade` method, so downgrade should have
> code like
> `ALTER TABLE server DROP COLUMN hostaddr `
> but in sqlite DROP COLUMN statements don't work.
> So, this is a an issue with Sqlite database. However, an alternative way
> is also given. Here is link
> <https://stackoverflow.com/questions/5938048/delete-column-from-sqlite-table>
>
>
> Still, I didn't find any other solution on upgrading/downgrading database
> revisions without errors.
> It is an issue with Flask-Migrate(Alembic) plugin.
>
Urgh. So I guess the other option is that we version the DB filename as
well. The downside of that is that users will want to migrate their
settings - which may be awkward as we'll have no real way of knowing where
they are.
Thoughts?
--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake
EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Harshal Dhumal | 2017-08-24 19:28:43 | Re: Next release |
Previous Message | Dave Cramer | 2017-08-24 12:34:36 | Re: [pgadmin4][Patch] Greenplum specific DDL and Dashboard display |