DacFx
DacFx copied to clipboard
microsoft
Default /p:AllowIncompatiblePlatform to true
Just sending feelers out for the community. Do you prefer the current, explicit behavior regarding targeted platform for a dacpac, or are you interested in a change to the default value of this parameter?
Please vote with reactions!
I personally don't see this happening. There are likely people out there who rely on the default value, and changing that default value could cause unexpected results. Changing default values on something that hasn't changed in years is usually high risk and not worth the change.
What is the effect of doing this?
The intended effect would be to allow easier portability of SQL projects between on-prem and cloud instances by removing the source for an easy mistake (using the default value for the creation of a project).
Does this not have the potential to introduce issues to those relying on the current default behavior?
Perhaps I'm misunderstanding how this flag works, but this is how I understand it:
Example: I have a single-tenant environment with hundreds of instances (one instance per customer). Let's say we are 99% of the way through an upgrade from SQL 2017 to SQL 2022, and we have already upgraded and tested our SSDT project to SQL 2022. If we were to perform a mass publish I would expect under the current default behavior for the deployments to the SQL 2017 instances to fail due to incompatible platforms. Perhaps the team performing the database release was unaware there were still SQL instances that had not yet been upgraded.
The current default behavior is fail-fast, which is probably safer. Changing the default to true requires having knowledge of your codebase and knowing that it will not fail due to incompatible code half way into the deployment.
If someone does have incompatible code, and this flag is set to true and you perform a publish...what happens? Do you just end up with a partial deployment?