You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
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.
Activity
doctrinebot commentedon May 19, 2015
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 commentedon May 28, 2015
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 commentedon Feb 10, 2016
Any updates on this? Would be nice to get rid of this in our version files
josensanchez commentedon Mar 15, 2016
As @doctrinebot commented, the problem seems to be here:
the first line builds the schema querying the database
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.
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 commentedon Aug 12, 2016
Yep, waiting issue to be resolved
garex commentedon Aug 26, 2016
Can't use
diff
commands as schema always differs by thoseCREATE SCHEMA public
.Local rude fix of doctrine/dbal#1110
Melkij commentedon Oct 24, 2016
My workaround without modify library and waiting patch.
Add class in any namespace in application:
Register event subscriber. For symfony this can be done in config:
Works for me, no more useless
CREATE SCHEMA public
in down migration.teohhanhui commentedon Oct 25, 2016
@Melkij What about other schemas? For example when using PostGIS.
garex commentedon 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.49 remaining items