Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Synonym foreign keys and stored procedures #359

Merged

Conversation

TimSirmovics
Copy link
Contributor

@TimSirmovics TimSirmovics commented Dec 4, 2017

Added support and test cases for foreign key navigation properties (#110) and stored procedures when referencing objects through synonyms.

@sjh37 sjh37 merged commit 4222c79 into sjh37:master Dec 4, 2017
@sjh37
Copy link
Owner

sjh37 commented Dec 4, 2017

Thanks Tim, much appreciated!

@sjh37 sjh37 mentioned this pull request Dec 4, 2017
@TimSirmovics TimSirmovics deleted the SynonymForeignKeysAndStoredProcedures branch December 28, 2017 22:01
sjh37 added a commit that referenced this pull request Jan 10, 2018
Bug introduced duplicate FK's which caused one-to-one to become
one-to-may.
@sjh37
Copy link
Owner

sjh37 commented Jan 10, 2018

Released in v2.35.0

@sjh37
Copy link
Owner

sjh37 commented Jan 10, 2018

@TimSirmovics I've corrected a slight bug in the SQL. I had to change "UNION ALL" to "UNION" to remove duplicates. The duplicates were causing the code to generate many-to-may FK relationships instead of one-to-one in certain circumstances.

@dialedin2014
Copy link

@sjh37 @TimSirmovics Hi guys. The database I am working has four tables, each setup like this:
Table1 (Synonym)
Table1_Load (Synonym)
Table1_A (Actual Table)
Table1_B (Actual Table)

In the tt file, I filter out everything but the synonym Table1.

The output does not have navigation properties.

I used SQL Profiler to obtain the SQL generated by Ef.Reverse.Poco.Core.ttinclude

This is the first statement with a resultset. It begins on line 230 of Profiler's output.

'
SELECT c.TABLE_SCHEMA AS SchemaName,
c.TABLE_NAME AS TableName,
t.TABLE_TYPE AS TableType,
c.ORDINAL_POSITION AS Ordinal,
c.COLUMN_NAME AS ColumnName,
CAST(CASE WHEN IS_NULLABLE = 'YES' THEN 1
ELSE 0
END AS BIT) AS IsNullable,
DATA_TYPE AS TypeName,
ISNULL(CHARACTER_MAXIMUM_LENGTH, 0) AS MaxLength,
CAST(ISNULL(NUMERIC_PRECISION, 0) AS INT) AS Precision,
ISNULL(COLUMN_DEFAULT, '') AS [Default],
CAST(ISNULL(DATETIME_PRECISION, 0) AS INT) AS DateTimePrecision,
ISNULL(NUMERIC_SCALE, 0) AS Scale,
CAST(COLUMNPROPERTY(OBJECT_ID(QUOTENAME(c.TABLE_SCHEMA) + '.' + QUOTENAME(c.TABLE_NAME)), c.COLUMN_NAME, 'IsIdentity') AS BIT) AS IsIdentity,
CAST(CASE WHEN COLUMNPROPERTY(OBJECT_ID(QUOTENAME(c.TABLE_SCHEMA) + '.' + QUOTENAME(c.TABLE_NAME)), c.COLUMN_NAME, 'IsIdentity') = 1 THEN 1
WHEN COLUMNPROPERTY(OBJECT_ID(QUOTENAME(c.TABLE_SCHEMA) + '.' + QUOTENAME(c.TABLE_NAME)), c.COLUMN_NAME, 'IsComputed') = 1 THEN 1
WHEN DATA_TYPE = 'TIMESTAMP' THEN 1
WHEN DATA_TYPE = 'UNIQUEIDENTIFIER'
AND LOWER(ISNULL(COLUMN_DEFAULT, '')) LIKE '%newsequentialid%' THEN 1
ELSE 0
END AS BIT) AS IsStoreGenerated,
CAST(CASE WHEN pk.ORDINAL_POSITION IS NULL THEN 0
ELSE 1
END AS BIT) AS PrimaryKey,
ISNULL(pk.ORDINAL_POSITION, 0) PrimaryKeyOrdinal,
CAST(CASE WHEN fk.COLUMN_NAME IS NULL THEN 0
ELSE 1
END AS BIT) AS IsForeignKey
FROM #Columns c
LEFT OUTER JOIN #PrimaryKeys pk
ON c.TABLE_SCHEMA = pk.TABLE_SCHEMA
AND c.TABLE_NAME = pk.TABLE_NAME
AND c.COLUMN_NAME = pk.COLUMN_NAME
LEFT OUTER JOIN #ForeignKeys fk
ON c.TABLE_SCHEMA = fk.TABLE_SCHEMA
AND c.TABLE_NAME = fk.TABLE_NAME
AND c.COLUMN_NAME = fk.COLUMN_NAME
INNER JOIN INFORMATION_SCHEMA.TABLES t
ON c.TABLE_SCHEMA COLLATE DATABASE_DEFAULT = t.TABLE_SCHEMA COLLATE DATABASE_DEFAULT
AND c.TABLE_NAME COLLATE DATABASE_DEFAULT = t.TABLE_NAME COLLATE DATABASE_DEFAULT
WHERE c.TABLE_NAME NOT IN ('EdmMetadata', '__MigrationHistory')
AND c.TABLE_NAME NOT LIKE 'sysdiagram%'
UNION
-- Synonyms
SELECT SchemaName, TableName, TableType, Ordinal, ColumnName, IsNullable, TypeName, [MaxLength], [Precision],
[Default], DateTimePrecision, Scale, IsIdentity, IsStoreGenerated, PrimaryKey, PrimaryKeyOrdinal, IsForeignKey FROM #SynonymDetails
'
The output includes the Synonyms, and correctly sets the IsForeignKey column.

Later on, the #SynonymFkDetails table is populated. I noticed it contains all the FKs in the database, but there doesn't seem to be anything to match them with Synonyms.

EF.Reverse.POCO.Core generated sql .txt

@TimSirmovics
Copy link
Contributor Author

Hi @dialedin2014,

I think you are correct in that the synonyms foreign keys do not work properly if the synonym and original table do not have the same name.

If you could submit a PR to fix this that would be great, otherwise I will try and look at it when I have time.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants