Include object types getting from DacFx enum #1553
Conversation
src/Microsoft.SqlTools.ServiceLayer/DacFx/Contracts/DeploymentOptions.cs
Outdated
Show resolved
Hide resolved
src/Microsoft.SqlTools.ServiceLayer/DacFx/Contracts/DeploymentOptions.cs
Outdated
Show resolved
Hide resolved
src/Microsoft.SqlTools.ServiceLayer/DacFx/Contracts/DeploymentOptions.cs
Outdated
Show resolved
Hide resolved
src/Microsoft.SqlTools.ServiceLayer/DacFx/Contracts/DeploymentOptions.cs
Outdated
Show resolved
Hide resolved
src/Microsoft.SqlTools.ServiceLayer/DacFx/Contracts/DeploymentOptions.cs
Show resolved
Hide resolved
| /// Gets include objects enum names and values as a dictionary | ||
| /// Ex: {key: Aggregate, value: 0} | ||
| /// </summary> | ||
| public void GetIncludeObjectTypesDictionary() |
There was a problem hiding this comment.
Methods with names starting with Get should generally be returning something - would suggest PopulateIncludeObjectTypesDictionary instead
| // Verify the include objects are not null | ||
| foreach (var includeObjType in options.IncludeObjects) | ||
| { | ||
| // Verify random include object types |
There was a problem hiding this comment.
- Why wouldn't you just check the types directly (
Assert.AreEqual(0, options.IncludeObjects["Aggregates"].Value))? Looping over the objects isn't really doing anything useful - You should use NUnit fluent assertions whenever possible (
Assert.That(includeObjType.Value, Is.EqualTo(0))). It's a lot more flexible, easier to work with and gives better error messages - If an assertion fails it needs to be obvious what's wrong from the log itself, in this case the message will just be something like
0 does not equal 5which isn't helpful for debugging. In cases like this you should add a further message to indicate the specific problem `Assert.That(options.IncludeObjects["Aggregates"], Is.EqualTo(0), "Aggregates key didn't have expected value")
Although I question the usefulness of this test to begin with - what's it actually verifying? If you just want to make sure the default options are populated then you could simply check the length or something - or if you wanted to check the values might as well check every item (the value should be the value of the enum)
| SetOptions(options); | ||
| } | ||
|
|
||
| /// <summary> | ||
| /// Gets include objects enum names and values as a dictionary | ||
| /// Ex: {key: Aggregate, value: 0} |
There was a problem hiding this comment.
like I mentioned in the other PR, does ADS need to know about the enum number of each object type? We should only need the name in ADS. If it's needed in in STS for converting before calling the DacServices apis, then a name to enum dictionary can be in STS.
There was a problem hiding this comment.
The reason for the enum numbers are these selected include objects are being send back to STS with the excludeObjectType property which holds the number of enum values. We can convert it to send back as values instead but there needs to be a conversion back to numbers when sending to DacFx. Let me know if you want me to do the conversion on STS and just sending enum values to the ADS. Thanks :)
There was a problem hiding this comment.
Now that the other options have to be converted anyway from the map to DacDeployOptions when coming back from ADS, it would make sense to only send the Schema Object names to ADS, then also do the conversion back to the enum values in STS
There was a problem hiding this comment.
what about the display names of these objects? Multiple word objects have a different display name from their enum name, like "StoredProcedure" has a space in the display name "Stored Procedure."
Right now, the display names are specified in the schema compare extension. Sql database projects will also need these, so it would be nice if the display names are also coming from STS so they aren't copied in 2 extensions.
| { | ||
| // Set include objects table data | ||
| var objectTypeEnum = typeof(ObjectType); | ||
| IncludeObjects = Enum.GetNames(objectTypeEnum).ToDictionary(t => t, t => (int)System.Enum.Parse(objectTypeEnum, t)); |
There was a problem hiding this comment.
using enum number is a bad idea. this means you cannot change the order of values in Enum in dacfx otherwise it can break ADs if the number is used in any extension. don't give any information you don't want any extension to use
|
This PR was spliced into two PRs and one was merged into main
|
These changes will avoid the duplication of options on extensions by simply getting the name from the DacFx enum.