On 9/22/15 7:24 PM, Mike Bayer wrote:
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
well, to clarify, alembic_version is created in that same connection
scope, so as long as the search path was set for every run it should be
in "public".
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
<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.
