On 9/22/15 6:49 PM, Sergi Pons Freixes wrote:
2015-09-22 15:06 GMT-07:00 Mike Bayer <mike...@zzzcomputing.com
<mailto:mike...@zzzcomputing.com>>:
OK, the only possible way this would happen is if "SELECT
current_schema()" were returning the name "notifications", and I
went back through our emails and found:
The output of the script is:
$ python inspector_test.py
default schema: notifications
schema names: ['information_schema', 'notifications', 'public']
dflt table names: ['alembic_version', 't1', 't2']
notifications table names: ['alembic_version', 't1', 't2']
that is the issue. If your search_path is set to only "public",
then current_schema should *NOT* be reading "notifications"; per
the docs
(http://www.postgresql.org/docs/9.2/static/functions-info.html):
|current_schema| returns the name of the schema that is first in
the search path (or a null value if the search path is empty).
This is the schema that will be used for any tables or other named
objects that are created without specifying a target schema.
So, is the username here the name "notifications"? since this
$user default is finding its way in there.
I would do this when you connect:
with engine.connect() as conn:
conn.execute("SET search_path='public'")
Yes, notifications is the name of the user AND the schema... not a
recommended practice I guess?
I set manually the search_path to only public as suggested, and prints
before and after show it during the revision:
...
INFO [sqlalchemy.engine.base.Engine] show search_path
INFO [sqlalchemy.engine.base.Engine] {}
('"$user",public',)
INFO [sqlalchemy.engine.base.Engine] SET search_path='public'
INFO [sqlalchemy.engine.base.Engine] {}
INFO [sqlalchemy.engine.base.Engine] show search_path
INFO [sqlalchemy.engine.base.Engine] {}
('public',)
...
Revision runs fine, but now when I run the upgrade it does not find
the alembic_version table (attached logs)... I suspect that the
search_path is restored so that it takes notifications again by default?
yes
Would this issue be solved just by $user!=$schema, or is there
something else behind (as you were saying, not even $user should be on
the search path)?
yes that would also solve it.
the issue is that PG doesn't give us the schema name of a foreign key
when that schema is in the search path. that's what the whole
explanation at
http://docs.sqlalchemy.org/en/rel_1_0/dialects/postgresql.html#remote-schema-table-introspection-and-postgresql-search-path
is about.
--
You received this message because you are subscribed to the Google
Groups "sqlalchemy-alembic" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to sqlalchemy-alembic+unsubscr...@googlegroups.com
<mailto:sqlalchemy-alembic+unsubscr...@googlegroups.com>.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
"sqlalchemy-alembic" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sqlalchemy-alembic+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
