Wrongfully detect dependency loop on views dependent on other views

[Glupschauge]

To Recreate:

database1: (Altering owner of views is crucial to recreate Bug)
`CREATE SCHEMA schema_a;

CREATE SCHEMA schema_b;

CREATE TABLE schema_a.table_a(
id integer NOT NULL,
some_data integer,
other_data integer
);

CREATE VIEW schema_a.view_a AS
SELECT t.id,
t.some_data
FROM schema_a.table_a t;

ALTER TABLE schema_a.view_a OWNER TO wvutomu;

CREATE VIEW schema_b.view_a AS
SELECT t.id,
t.some_data
FROM schema_a.view_a t;

ALTER TABLE schema_b.view_a OWNER TO wvutomu;

GRANT SELECT ON TABLE schema_b.view_a TO wvutomu;`

database2: (empty)

Generate yaml:
dbtoyaml -o database1.yaml database1

Generating diff:
yamltodb database2 database1.yaml

Results in:
Exception: the objects dependencies graph has loops

I printed the dependencies of the Function objects:
<view view_a at 0x28e1cf0> depends on: {<schema schema_b at 0x28e1c70>, <view view_a at 0x28e1cf0>}

This shows that the view is dependend on it self.

[jmafc]

I will attempt to reproduce later but if you can please post the views respecitve depends_on: sections? Is the depends_on for schema_b.view_a a fully-qualified name, i.e., schema_a.view_a and not simply view_a (if it's not schema-qualified, the problem would start in dbtoyaml)?

[jmafc]

I've now confirmed this problem and as I had suspected, the problem apparently starts with dbtoyaml since it outputs schema_b.view_a with an unqualified depends_on name:

schema schema_b:
...
    definition: |2-
       SELECT t.id,
          t.some_data
         FROM schema_a.view_a t;
    depends_on:
    - view view_a

The problem appears to be with DbObject.to_map using dep.extern_key() when constructing the depends_on attribute. The default extern_key, per the comments, uses the "non-schema-qualified-name". This in general is OK because an object within a schema is owned by that schema, but in this case we have a cross-schema relationship. @dvarrazzo It seems the to_map has to do something special or request extern_key to return a schema-qualified name when it can detect a cross-schema relationship. What do you think?