Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DBAL-1168: Schema's getMigrateFromSql always adds CREATE SCHEMA #1110

Closed
doctrinebot opened this issue Mar 11, 2015 · 39 comments
Closed

DBAL-1168: Schema's getMigrateFromSql always adds CREATE SCHEMA #1110

doctrinebot opened this issue Mar 11, 2015 · 39 comments

Comments

@doctrinebot
Copy link

Jira issue originally created by user vbence:

I originally posted this to Migrations; noticing that all the generated down() methods start with a "CREATE SCHEMA public" line.

Inspecting the return from Schema#getMigrateFromSql it indeed contains the create statement.

@doctrinebot
Copy link
Author

Comment created by asentner:

I am also having this issue. The down() method always adds: $this->addSql('CREATE SCHEMA public');

Same environment, also using Postgres.

Any chance this is on anyone's radar for a release in the near future?

@doctrinebot
Copy link
Author

Comment created by acasademont:

Hit by this too. The problem seems to be that the "public" namespace is not added to the table names by default and hence the diff between what postgres says (a "public" schema is created by default in the DB) and what our schema says.

I tried to solve this with a workaround by prepending "public." to all table names. It works for the first migration but then in the next migration will try to delete all tables without the "public." and create them again. So that's not working!

The solution is assuming that there's always a default 'public' namespace in the Schema.php class.

@cleentfaar
Copy link

Any updates on this? Would be nice to get rid of this in our version files

@josensanchez
Copy link

As @doctrinebot commented, the problem seems to be here:

        $fromSchema = $conn->getSchemaManager()->createSchema();
        $toSchema = $this->getSchemaProvider()->createSchema();

the first line builds the schema querying the database

SELECT schema_name AS nspname
          FROM   information_schema.schemata
...

and the second one builds it from the ORM metadata in your application

@ORM\Table(name="table_1" ...

there is a "public" schema in $fromSchema but since there is no @ORM\Table(name="table_1", schema="public"...) also there is no "public" schema in $toSchema

trying the @doctrinebot workaround @ORM\Table(name="table_1", schema="public"...) it's also useless as he already commented because table_1 and public.table_1 are two different things to the dbal, witch is logic.
but it will try to perform the next code every time.

create table public.table_1 ...  -- table already exists exception
drop table table_1

the drop command is without the "public." and I assume that it's to add support to tables without namespaces...

I don't see an easy solution for this issue. Either finding a way to define table_1 as an alias for public.table_1 (maybe in postgresql if a database object doesn't have a namespace defined, then the 'public' namespace is attached to it) or removing support in postgresql for no namespace objects, forcing always to define schema="public"

for the moment if anybody is working with postgresql and doctrine I suggest to use only the public schema or not use it at all.

@idchlife
Copy link

Yep, waiting issue to be resolved

@garex
Copy link

garex commented Aug 26, 2016

Can't use diff commands as schema always differs by those CREATE SCHEMA public.

garex added a commit to ekapusta/doctrine-phinx-bridge-bundle that referenced this issue Aug 27, 2016
* Need to revert this after fixes in dbal and orm upstreams
@Melkij
Copy link

Melkij commented Oct 24, 2016

My workaround without modify library and waiting patch.
Add class in any namespace in application:

<?php

namespace EngineBundle\Doctrine;

use Doctrine\Common\EventSubscriber;
use Doctrine\ORM\Tools\Event\GenerateSchemaEventArgs;

class MigrationEventSubscriber implements EventSubscriber
{
    public function getSubscribedEvents()
    {
        return array(
            'postGenerateSchema',
        );
    }

    public function postGenerateSchema(GenerateSchemaEventArgs $Args)
    {
        $Schema = $Args->getSchema();

        if (! $Schema->hasNamespace('public')) {
            $Schema->createNamespace('public');
        }
    }
}

Register event subscriber. For symfony this can be done in config:

# app/config/services.yml
services:
    doctrineMigrationDiffListener:
        class: EngineBundle\Doctrine\MigrationEventSubscriber
        tags:
            - { name: doctrine.event_subscriber, connection: default }

Works for me, no more useless CREATE SCHEMA public in down migration.

@teohhanhui
Copy link

@Melkij What about other schemas? For example when using PostGIS.

@garex
Copy link

garex commented Oct 25, 2016

@teohhanhui see my PR #2490

There is $platform->getDefaultSchemaName() -- then it will be unversal. Currently 'public' is hardcoded value in this solution.

@Melkij
Copy link

Melkij commented Oct 25, 2016

@teohhanhui I test only public schema. This is just workaround for my project, not complete solution.
I think same hasNamespace + createNamespace needed for any schemas, which is not used in any Entity. And for schemas in search_path setting.

@vudaltsov
Copy link

Created a bundle addressing this issue

@isaackearl
Copy link

isaackearl commented Jul 1, 2017

If you are using the Laravel doctrine package, here is a workaround: laravel-doctrine/migrations#51

@alemosk
Copy link

alemosk commented Jul 13, 2017

If it very old and very hard bug, why not replace constant 'CREATE SCHEMA ' to 'CREATE SCHEMA IF NOT EXISTS ' ?

Not beauty, but will no exceptions.

@Ocramius
Copy link
Member

Ocramius commented Jul 13, 2017 via email

@vudaltsov
Copy link

vudaltsov commented Dec 16, 2017

I think, I found a cleaner solution. At least for PostgreSQL.
And it looks like it follows @deeky666's advice in #2490 (comment) since it uses AbstractSchemaManager::getSchemaSearchPaths() through PostgreSqlSchemaManager::determineExistingSchemaSearchPaths().

<?php

declare(strict_types=1);

namespace App\EventListener;

use Doctrine\Common\EventSubscriber;
use Doctrine\DBAL\Schema\PostgreSqlSchemaManager;
use Doctrine\ORM\Tools\Event\GenerateSchemaEventArgs;
use Doctrine\ORM\Tools\ToolEvents;

class FixDefaultSchemaListener implements EventSubscriber
{
    /**
     * {@inheritdoc}
     */
    public function getSubscribedEvents(): array
    {
        return [
            ToolEvents::postGenerateSchema,
        ];
    }

    public function postGenerateSchema(GenerateSchemaEventArgs $args): void
    {
        $schemaManager = $args->getEntityManager()
            ->getConnection()
            ->getSchemaManager();

        if (!$schemaManager instanceof PostgreSqlSchemaManager) {
            return;
        }

        foreach ($schemaManager->getExistingSchemaSearchPaths() as $namespace) {
            if (!$args->getSchema()->hasNamespace($namespace)) {
                $args->getSchema()->createNamespace($namespace);
            }
        }
    }
}

@yurtesen
Copy link

I have also faced with this problem.

@greg0ire
Copy link
Member

@vudaltsov I don't think this bug happens on anything but Postgres, does it? Maybe create a PR?

@antonmedv
Copy link

Any updates?

@Ocramius
Copy link
Member

@antonmedv can you provide a failing test case for the DBAL test suite?

@PedroDiSanti
Copy link

Is this bug still occurring while using Symfony 4 + Postgres?
Thanks for any help!

@mneute
Copy link

mneute commented Nov 8, 2018

@PedroDiSanti : Yes, this is still occuring

@PedroDiSanti
Copy link

@PedroDiSanti : Yes, this is still occuring

Thanks, mate.

@melyouz
Copy link

melyouz commented Dec 23, 2018

This is still occuring. Even when there are no migrations to generate, the following line is added:

$this->addSql('CREATE SCHEMA public');

Full generated migration content could be found here.

@vasilvestre
Copy link

Still occurring, got some fresh news?

@Ocramius
Copy link
Member

@vasilvestre pick up #2490 if you can work on it.

@ghost
Copy link

ghost commented Jan 14, 2019

Anyone know how to implement #1110 (comment) into a symfony4 project? What yaml file does it go into, and where?

Any help would be awesome.

@vudaltsov
Copy link

@pc-trent , https://gist.github.com/vudaltsov/ec01012d3fe27c9eed59aa7fd9089cf7

@ghost
Copy link

ghost commented Jan 29, 2019

@vudaltsov - legend thanks!

gregtyler added a commit to ministryofjustice/opg-digi-deps-api that referenced this issue May 28, 2019
The command doesn't work and is incorrectly added by DBAL: doctrine/dbal#1110
gregtyler added a commit to ministryofjustice/opg-digi-deps-api that referenced this issue May 29, 2019
* Stop trying to create schema in down migrations

* Remove `CREATE SCHEMA public` from migrations

The command doesn't work and is incorrectly added by DBAL: doctrine/dbal#1110

* Update syntax to match code style

* Remove event listener services to separate file

* Remove deprecated step from rollback procedure

You don't need to remove `CREATE SCHEMA public` commands now because this PR does it for you

* Update deleted directory

Deleting `var/cache` itself causes a permissions mishap. Instead, delete the contents of that directory like every other script does.
dtsadok pushed a commit to dtsadok/CharityCrowd that referenced this issue Mar 9, 2021
@Autsider666
Copy link

@vudaltsov 2 years later and you're still a legend!

@aleksandrphilippov
Copy link

@vudaltsov Any updates?

@TheFox
Copy link

TheFox commented Apr 7, 2022

@vudaltsov 3 years later and you're still a legend.

@greg0ire
Copy link
Member

greg0ire commented Apr 7, 2022

Notes to self:

Doesn't this mean this is actually a bug in doctrine/migrations (since it's building the desired schema)? If yes, should @Melkij / @vudaltsov 's fix be implemented in doctrine/migrations + DoctrineMigrationsBundle?

@myselfhimself
Copy link

Thanks!
Very good to fix the following error on PostgreSQL + symfony + doctrine:

 Creating database schema...


In ToolsException.php line 19:
                                                                                                                                                                                                        
  Schema-Tool failed with Error 'An exception occurred while executing a query: SQLSTATE[42P06]: Duplicate schema: 7 ERROR:  schema "public" already exists' while executing DDL: CREATE SCHEMA public  
                                                                                                                                                                                                        

In ExceptionConverter.php line 87:
                                                                                                                              
  An exception occurred while executing a query: SQLSTATE[42P06]: Duplicate schema: 7 ERROR:  schema "public" already exists  
                                                                                                                              

In Exception.php line 28:
                                                                               
  SQLSTATE[42P06]: Duplicate schema: 7 ERROR:  schema "public" already exists  
                                                                               

In Connection.php line 69:
                                                                               
  SQLSTATE[42P06]: Duplicate schema: 7 ERROR:  schema "public" already exists  
                                                                               

doctrine:schema:create [--em EM] [--dump-sql]

@myselfhimself
Copy link

Hmm actually it is problematic for doctrine:schema:create, here is a variant fix:

<?php

namespace EngineBundle\Doctrine;

use Doctrine\Common\EventSubscriber;
use Doctrine\ORM\Tools\Event\GenerateSchemaEventArgs;

/**
 * @see https://github.com/doctrine/dbal/issues/1110#issuecomment-255765189
 */
class MigrationEventSubscriber implements EventSubscriber
{
    public function getSubscribedEvents()
    {
        return array(
            'postGenerateSchema',
        );
    }

    public function postGenerateSchema(GenerateSchemaEventArgs $Args)
    {
        // This listener helps to prevent generating 'down' migrations trying to remove a 'public' schema for ever
        // however it confuses the doctrine:schema:create command which tries to recreate a 'public' table.
        // The workaround is to run doctrine:schema:create command with the following environment variable
        // set to a non-empty value, then unsetting that variable forever.
        if(empty(getenv('NO_PUBLIC_SCHEMA_CREATE_PLEASE'))) {
            $Schema = $Args->getSchema();

            if (! $Schema->hasNamespace('public')) {
                $Schema->createNamespace('public');
            }
        }
    }
}

And running the doctrine:schema:create command:
NO_PUBLIC_SCHEMA_CREATE_PLEASE=yes php bin/console doctrine:schema:create
But that environment variable is removed for all cases:
php bin/console make:migration

@github-actions
Copy link

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Oct 31, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests