On 9/22/15 3:43 PM, Sergi Pons Freixes wrote:
2015-09-22 11:52 GMT-07:00 Sergi Pons Freixes <sachiel2...@gmail.com
<mailto:sachiel2...@gmail.com>>:
2015-09-22 10:41 GMT-07:00 Mike Bayer <mike...@zzzcomputing.com
<mailto:mike...@zzzcomputing.com>>:
So one more time, with all detail possible; attached is an
env.py script and a full log of all SQL emitted and commands;
we have alembic_version is created in "public", the two tables
created only in "notifications", no redundant FK commands in
the next run. Please start with a brand new, definitely
completely empty PG database, no dependencies, and run this
env.py as is without any of your application being imported,
then do a line-by-line on your logs vs. the logs (use logging
config in attached alembic.ini) here to see where they
diverge. thanks!
Could you reproduce that?
Ok, I reproduced it on a new database I changed nothing except the
script location in the ini file, and the second revision was fine,
no foreign keys dropped. I'll now slowly change this "good" env.py
and .ini to make it more like my previous one, and see when the
issue starts triggering.
First of all, thank you for your patience all this time, Mike. Next,
some more results. I just discovered that just switching between
databases, not changing env.py or .ini at all (except to point to the
new DB, and I added a print to the search_path), things start to
differ. I attach the logs of the first revision, when the tables are
created for the first time, being test_first_revision.log related to
the new fresh database and notifications_first_revision.log related to
the old database (but with all the previous tables dropped). Checking
with pgAdmin, both have 'public' as the default schema, and the print
of search_path shows only $user and public.
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'")
--
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.
