Re: Drop followed by generation of Foreign Keys

[Sergi Pons Freixes]

2015-09-21 18:31 GMT-07:00 Mike Bayer :

>
> OK great, I can now show something similar happening. Your model has
> tables t1 and t2 in *both* the public and notifications schema and I'm
> assuming the same foreign key setup.
>
> In many of your examples I've observed the explicit use of "public":
>
> __table_args__ = {'schema': 'public'}
>
> That has to be removed entirely.When I have all four tables and I use
> "public" explicitly, the reflection system cannot get enough information to
> make a decision, based on the information in the section I originally
> referred to at
> http://docs.sqlalchemy.org/en/rel_1_0/dialects/postgresql.html#remote-schema-table-introspection-and-postgresql-search-path
> - see the yellow sidebar box at the bottom of the section for a quick
> summary.
>
> When I remove the redundant "public" schema from my table defs, the
> redundant FK defs go away.
>

Mmmm, but:
- Before each test, I was dropping all the tables on the 'public' and
'notifications' schemas, and I made sure they were empty. So there should
never be  both tables on both schemas.
- Each time, I was running alembic twice: first time to create the tables
(and I checked that they were on the expected schema), second time to
experience the dropping/recreation of keys.

I agree that the first snippets that I copy-pasted were confusing, so I
decided to limit the tests just to the env.py I attached previously,
dropping the tables for a clean state. In this code I am only referencing
to 'notifications' with "__table_args__ = {'schema': 'notifications'}", and
'public' is never used. With it, t1, t2 and alembic_versions are created
all on 'notifications', an nothing in 'public'.

Could you reproduce that?

-- 
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.

Re: Drop followed by generation of Foreign Keys

[Sergi Pons Freixes]

Additional update: If on the env.py I substitute "__table_args__ =
{'schema': 'notifications'}" for "__table_args__ = {'schema':
'notifications'}" and rerun alembic twice again (assuming we start on a
clean database), alembic_version is created on the 'notifications' schema,
t1 and t2 on 'notifications' schema, and the issue is done (i.e., the
second run of alembic does nothing).

-- 
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.

Re: Drop followed by generation of Foreign Keys

[Mike Bayer]

On 9/22/15 1:17 PM, Sergi Pons Freixes wrote:



2015-09-21 18:31 GMT-07:00 Mike Bayer >:



OK great, I can now show something similar happening. Your
model has tables t1 and t2 in *both* the public and notifications
schema and I'm assuming the same foreign key setup.

In many of your examples I've observed the explicit use of "public":

__table_args__ = {'schema': 'public'}

That has to be removed entirely.When I have all four tables
and I use "public" explicitly, the reflection system cannot get
enough information to make a decision, based on the information in
the section I originally referred to at

http://docs.sqlalchemy.org/en/rel_1_0/dialects/postgresql.html#remote-schema-table-introspection-and-postgresql-search-path
- see the yellow sidebar box at the bottom of the section for a
quick summary.

When I remove the redundant "public" schema from my table defs,
the redundant FK defs go away.


Mmmm, but:
- Before each test, I was dropping all the tables on the 'public' and 
'notifications' schemas, and I made sure they were empty. So there 
should never be  both tables on both schemas.
do you *want* both tables in both schemas?   that's what came up with 
you ran the inspector lines I showed you.   If your alembic config 
created the tables twice in both schemas then there is a lot more going 
on than just a foreign key issue.


I agree that the first snippets that I copy-pasted were confusing, so 
I decided to limit the tests just to the env.py I attached previously, 
dropping the tables for a clean state. In this code I am only 
referencing to 'notifications' with "__table_args__ = {'schema': 
'notifications'}", and 'public' is never used. With it, t1, t2 and 
alembic_versions are created all on 'notifications', an nothing in 
'public'.


Alembic never adds a schema qualifier to the alembic_version table 
unless you specify one.   So it's not possible that the table is created 
in "notifications", *unless* your postgresql configuration is such that 
your *current* schema (defined as, the first schema in search_path) when 
you connect is "notifications".  Which we've established that it's not.


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?
--
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.


--
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.
from __future__ import with_statement
from alembic import context
from sqlalchemy import engine_from_config, pool
from logging.config import fileConfig

# this is the Alembic Config object, which provides
# access to the values within the .ini file in use.
config = context.config

# Interpret the config file for Python logging.
# This line sets up loggers basically.
fileConfig(config.config_file_name)

from sqlalchemy import Column, Integer, ForeignKey
from sqlalchemy.ext.declarative import declarative_base

Base = declarative_base()

class t1(Base):
__tablename__='t1'
__table_args__ = {'schema': 'notifications'}

id = Column(Integer, primary_key=True)
def __init__(self):
pass

class t2(Base):
__tablename__='t2'
__table_args__ = {'schema': 'notifications'}
id = Column(Integer, primary_key=True)
t1id = Column('t1id', Integer, ForeignKey(t1.id))

def __init__(self, t1id=None):
self.t1id = t1id

# add your model's MetaData object here
# for 'autogenerate' support
# from myapp import mymodel
# target_metadata = mymodel.Base.metadata
target_metadata = Base.metadata

# other values from the config, defined by the needs of env.py,
# can be acquired:
# my_important_option = config.get_main_option("my_important_option")
# ... etc.


def run_migrations_offline():
"""Run migrations in 'offline' mode.

This configures the context with just a URL
and not an Engine, though an Engine is acceptable
here as well.  By s

Re: Drop followed by generation of Foreign Keys

[Mike Bayer]

On 9/22/15 1:41 PM, Sergi Pons Freixes wrote:
Additional update: If on the env.py I substitute "__table_args__ = 
{'schema': 'notifications'}" for "__table_args__ = {'schema': 
'notifications'}" and rerun alembic twice again (assuming we start on 
a clean database), alembic_version is created on the 'notifications' 
schema, t1 and t2 on 'notifications' schema, and the issue is done 
(i.e., the second run of alembic does nothing).


does your PG database have some kind of replication or triggering 
happening that is duplicating tables between the two schemas? Please run 
everything clean with full logging turned on as I illustrated in my 
previous email, you should only see "CREATE TABLE alembic_version" 
without any schema qualifier.





--
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.


--
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.

Re: Drop followed by generation of Foreign Keys

[Sergi Pons Freixes]

2015-09-22 10:44 GMT-07:00 Mike Bayer :

>
>
> On 9/22/15 1:41 PM, Sergi Pons Freixes wrote:
>
> Additional update: If on the env.py I substitute "__table_args__ =
> {'schema': 'notifications'}" for "__table_args__ = {'schema':
> 'notifications'}" and rerun alembic twice again (assuming we start on a
> clean database), alembic_version is created on the 'notifications' schema,
> t1 and t2 on 'notifications' schema, and the issue is done (i.e., the
> second run of alembic does nothing).
>
>
> does your PG database have some kind of replication or triggering
> happening that is duplicating tables between the two schemas?   Please run
> everything clean with full logging turned on as I illustrated in my
> previous email, you should only see "CREATE TABLE alembic_version" without
> any schema qualifier.
>

Just to be sure: I should create a new database (test) AND the
'notifications' schema, right? Alembic shouldn't be able to create t1 and
t2 if the schema didn't exist previously.

-- 
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.

Re: Drop followed by generation of Foreign Keys

[Mike Bayer]

On 9/22/15 2:25 PM, Sergi Pons Freixes wrote:
2015-09-22 10:44 GMT-07:00 Mike Bayer >:




On 9/22/15 1:41 PM, Sergi Pons Freixes wrote:

Additional update: If on the env.py I substitute "__table_args__
= {'schema': 'notifications'}" for "__table_args__ = {'schema':
'notifications'}" and rerun alembic twice again (assuming we
start on a clean database), alembic_version is created on the
'notifications' schema, t1 and t2 on 'notifications' schema, and
the issue is done (i.e., the second run of alembic does nothing).


does your PG database have some kind of replication or triggering
happening that is duplicating tables between the two schemas?  
Please run everything clean with full logging turned on as I

illustrated in my previous email, you should only see "CREATE
TABLE alembic_version" without any schema qualifier.


Just to be sure: I should create a new database (test) AND the 
'notifications' schema, right? Alembic shouldn't be able to create t1 
and t2 if the schema didn't exist previously.


yes, alembic doesnt create the schema for you.



--
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.


--
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.

Re: Drop followed by generation of Foreign Keys

[Sergi Pons Freixes]

2015-09-22 10:41 GMT-07:00 Mike Bayer :

>
> 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.

-- 
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.

Re: Drop followed by generation of Foreign Keys

[Sergi Pons Freixes]

2015-09-22 11:52 GMT-07:00 Sergi Pons Freixes :

> 2015-09-22 10:41 GMT-07:00 Mike Bayer :
>
>>
>> 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.

-- 
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.


test_first_revision.log
Description: Binary data


notifications_first_revision.log
Description: Binary data

Re: Drop followed by generation of Foreign Keys

[Mike Bayer]

On 9/22/15 3:43 PM, Sergi Pons Freixes wrote:



2015-09-22 11:52 GMT-07:00 Sergi Pons Freixes >:


2015-09-22 10:41 GMT-07:00 Mike Bayer 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 
.

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.

Re: Drop followed by generation of Foreign Keys

[Sergi Pons Freixes]

2015-09-22 15:06 GMT-07:00 Mike Bayer :

> 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?

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)?

-- 
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.


revision.log
Description: Binary data


upgrade.log
Description: Binary data

Re: Drop followed by generation of Foreign Keys

[Mike Bayer]

On 9/22/15 6:49 PM, Sergi Pons Freixes wrote:
2015-09-22 15:06 GMT-07:00 Mike Bayer >:


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 
.

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.

Re: Drop followed by generation of Foreign Keys

[Mike Bayer]

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 >:


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 
.

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.


--
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.

Re: Drop followed by generation of Foreign Keys

[Sergi Pons Freixes]

2015-09-22 16:24 GMT-07:00 Mike Bayer :

> 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.
>

Setting the database search_path to 'public' permanently using pgAdmin
solved the problem:

ALTER DATABASE notifications
  SET search_path = public;

Now it remains always as 'public', and everything seems to run fine. I'll
now apply that to the other databases that were also having this issue. I
guess this issue can be declared close, thank you very much for all your
help!

Regards,
Sergi

-- 
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.