[DBAL-54] [DBAL-420] Cannot drop schema using IDENTITY strategy in PostgreSQL #289

Merged
merged 1 commit into from Apr 14, 2013

Conversation

Projects
None yet
3 participants
@PowerKiKi
Contributor

PowerKiKi commented Mar 22, 2013

DBAL-54 was fixed in commit 3d55dc8 by
changing SQL queries order. However it was later reintroduced.

This patch uses a different, more future-proof way, approach by using
DROP SEQUENCE ... CASCADE syntax, and thus does not depend on queries order.

[DBAL-54] Cannot drop schema using IDENTITY strategy in PostgreSQL
DBAL-54 was fixed in commit 3d55dc8 by
changing SQL queries order. However it was later reintroduced.

This patch uses a different, more future-proof way, approach by using
DROP SEQUENCE ... CASCADE syntax, and thus does not depend on queries order.
@doctrinebot

This comment has been minimized.

Show comment Hide comment
@doctrinebot

doctrinebot Mar 22, 2013

Hello,

thank you for positing this Pull Request. I have automatically opened an issue on our Jira Bug Tracker for you with the details of this Pull-Request. See the Link:

http://doctrine-project.org/jira/browse/DBAL-420

Hello,

thank you for positing this Pull Request. I have automatically opened an issue on our Jira Bug Tracker for you with the details of this Pull-Request. See the Link:

http://doctrine-project.org/jira/browse/DBAL-420

@beberlei

This comment has been minimized.

Show comment Hide comment
@beberlei

beberlei Apr 14, 2013

Member

From http://www.postgresql.org/docs/8.3/static/sql-dropsequence.html:

CASCADE Automatically drop objects that depend on the sequence.

Does this mean tables? Or just the DEFAULT constraints on the tables?

Member

beberlei commented Apr 14, 2013

From http://www.postgresql.org/docs/8.3/static/sql-dropsequence.html:

CASCADE Automatically drop objects that depend on the sequence.

Does this mean tables? Or just the DEFAULT constraints on the tables?

@beberlei

This comment has been minimized.

Show comment Hide comment
@beberlei

beberlei Apr 14, 2013

Member

@PowerKiKi ping :)

Member

beberlei commented Apr 14, 2013

@PowerKiKi ping :)

@PowerKiKi

This comment has been minimized.

Show comment Hide comment
@PowerKiKi

PowerKiKi Apr 14, 2013

Contributor

As you can see in the following test (on PotsgreSQL 9.1) the table will not be dropped, but the column default value will be changed.

Basically what happens:

  1. create table
  2. check that both sequence and table exist
  3. drop sequence (fail without cascade)
  4. drop sequence with cascade
  5. check that sequence was dropped, but table still exists (with no default anymore)
database=# CREATE TABLE test (id SERIAL);
NOTICE:  CREATE TABLE will create implicit sequence "test_id_seq" for serial column "test.id"
CREATE TABLE
database=# \d test_id_seq 
         Sequence "public.test_id_seq"
    Column     |  Type   |        Value        
---------------+---------+---------------------
 sequence_name | name    | test_id_seq
 last_value    | bigint  | 1
 start_value   | bigint  | 1
 increment_by  | bigint  | 1
 max_value     | bigint  | 9223372036854775807
 min_value     | bigint  | 1
 cache_value   | bigint  | 1
 log_cnt       | bigint  | 0
 is_cycled     | boolean | f
 is_called     | boolean | f
Owned by: public.test.id

database=# \d test
                         Table "public.test"
 Column |  Type   |                     Modifiers                     
--------+---------+---------------------------------------------------
 id     | integer | not null default nextval('test_id_seq'::regclass)

database=# DROP SEQUENCE test_id_seq;
ERROR:  cannot drop sequence test_id_seq because other objects depend on it
DETAIL:  default for table test column id depends on sequence test_id_seq
HINT:  Use DROP ... CASCADE to drop the dependent objects too.
database=# DROP SEQUENCE test_id_seq CASCADE;
NOTICE:  drop cascades to default for table test column id
DROP SEQUENCE
database=# DROP SEQUENCE test_id_seq;
ERROR:  sequence "test_id_seq" does not exist
database=# \d test
     Table "public.test"
 Column |  Type   | Modifiers 
--------+---------+-----------
 id     | integer | not null

database=# SHOW SERVER_VERSION;
 server_version 
----------------
 9.1.9
(1 row)

So to me, it seems pretty clear that there is no risk of data loss. Unless there are other use-case for sequences involving other type of dependent objects. But I am not aware of any.

Contributor

PowerKiKi commented Apr 14, 2013

As you can see in the following test (on PotsgreSQL 9.1) the table will not be dropped, but the column default value will be changed.

Basically what happens:

  1. create table
  2. check that both sequence and table exist
  3. drop sequence (fail without cascade)
  4. drop sequence with cascade
  5. check that sequence was dropped, but table still exists (with no default anymore)
database=# CREATE TABLE test (id SERIAL);
NOTICE:  CREATE TABLE will create implicit sequence "test_id_seq" for serial column "test.id"
CREATE TABLE
database=# \d test_id_seq 
         Sequence "public.test_id_seq"
    Column     |  Type   |        Value        
---------------+---------+---------------------
 sequence_name | name    | test_id_seq
 last_value    | bigint  | 1
 start_value   | bigint  | 1
 increment_by  | bigint  | 1
 max_value     | bigint  | 9223372036854775807
 min_value     | bigint  | 1
 cache_value   | bigint  | 1
 log_cnt       | bigint  | 0
 is_cycled     | boolean | f
 is_called     | boolean | f
Owned by: public.test.id

database=# \d test
                         Table "public.test"
 Column |  Type   |                     Modifiers                     
--------+---------+---------------------------------------------------
 id     | integer | not null default nextval('test_id_seq'::regclass)

database=# DROP SEQUENCE test_id_seq;
ERROR:  cannot drop sequence test_id_seq because other objects depend on it
DETAIL:  default for table test column id depends on sequence test_id_seq
HINT:  Use DROP ... CASCADE to drop the dependent objects too.
database=# DROP SEQUENCE test_id_seq CASCADE;
NOTICE:  drop cascades to default for table test column id
DROP SEQUENCE
database=# DROP SEQUENCE test_id_seq;
ERROR:  sequence "test_id_seq" does not exist
database=# \d test
     Table "public.test"
 Column |  Type   | Modifiers 
--------+---------+-----------
 id     | integer | not null

database=# SHOW SERVER_VERSION;
 server_version 
----------------
 9.1.9
(1 row)

So to me, it seems pretty clear that there is no risk of data loss. Unless there are other use-case for sequences involving other type of dependent objects. But I am not aware of any.

beberlei added a commit that referenced this pull request Apr 14, 2013

Merge pull request #289 from PowerKiKi/DBAL-54-bis
[DBAL-54] [DBAL-420] Cannot drop schema using IDENTITY strategy in PostgreSQL

@beberlei beberlei merged commit cb9f1ad into doctrine:master Apr 14, 2013

1 check passed

default The Travis build passed
Details

@PowerKiKi PowerKiKi deleted the PowerKiKi:DBAL-54-bis branch Apr 14, 2013

@beberlei

This comment has been minimized.

Show comment Hide comment
@beberlei

beberlei Apr 14, 2013

Member

Ok, perfect!

Merged into master and 2.3 release branch

Member

beberlei commented Apr 14, 2013

Ok, perfect!

Merged into master and 2.3 release branch

@PowerKiKi

This comment has been minimized.

Show comment Hide comment
@PowerKiKi

PowerKiKi Apr 14, 2013

Contributor

thanks 👍

Contributor

PowerKiKi commented Apr 14, 2013

thanks 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment