Deployment results in non-clustered index being rebuilt on table with partitioned index #202
Description
When a table has a partitioned index and a non-clustered index, deploying the dacpac without any changes still result in the non-clustered index being rebuilt.
Repro by creating a sqlproj with this script:
ALTER DATABASE [$(DatabaseName)]
ADD FILEGROUP [Negative];
GO
ALTER DATABASE [$(DatabaseName)]
ADD FILEGROUP [Zero];
GO
ALTER DATABASE [$(DatabaseName)]
ADD FILEGROUP [Positive];
GO
CREATE PARTITION FUNCTION [PartitionFunctionBySign](INT)
AS RANGE
FOR VALUES (0, 1);
GO
CREATE PARTITION SCHEME [SignedPartitions]
AS PARTITION [PartitionFunctionBySign]
TO ([Negative], [Zero], [Positive]);
GO
CREATE TABLE [dbo].[Table1]
(
[Id] INT NOT NULL,
[Quantity] INT NOT NULL,
[Quantity2] INT NOT NULL,
CONSTRAINT [PK_Table1] PRIMARY KEY
CLUSTERED ([Id], [Quantity])
ON [SignedPartitions] ([Quantity])
);
GO
CREATE NONCLUSTERED INDEX IX_Table1
ON [dbo].[Table1] ([Quantity2])
WITH (DATA_COMPRESSION = ROW);
GODeploying the same dacpac a second time without any changes, sqlpackage will still generate a script to rebuild the non-clustered index. Deployment is successful however it adds an unnecessary step and is problematic for large tables.
PRINT N'Altering SqlIndex [dbo].[Table1].[IX_Table1]...';
GO
ALTER INDEX [IX_Table1]
ON [dbo].[Table1] REBUILD WITH(DATA_COMPRESSION = ROW);
GOI suspect the bug lies within the Reverse Engineering logic as the extracted dacpac has some differences to the original dacpac built from sqlproj.