Description
Feedback from #1801 (comment), below optimization should be done to keep up with SMO's latest APIs and design:
-
Try to remove the redundancy of the XML and C# code. Couldn't the node builder pick up the property list from the deserialized XML objects instead of requiring a duplicate code object that returns the same property list?
-
Try to get rid of the "ValidFor" stuff and delay the check until issuing the SMO query. The Server object in SMO now has a version of IsSupportedProperty for this. The node just needs a way to determine which properties were actually set during initialization so it doesn't try to use the unset ones. I suggest this because Azure gets new stuff pretty quickly, and properties that were only valid on sql box for a while become valid on cloud, and ideally we could just pick up a new SMO drop for that and have it "just work" with no STS code changes.
/// <summary>
/// Returns true if the given property name is valid for the object of Type type for the Server's version and edition.
/// </summary>
/// <param name="type">A type that is assignable to SqlSmoObject</param>
/// <param name="propertyName"></param>
/// <param name="databaseEngineEdition">Specific database edition to check for property supported. If Unknown or not specified, the check will use the edition of the master database.</param>
/// <returns>true if the property can be requested, false otherwise</returns>
/// <exception cref="ArgumentException">When type is not a SqlSmoObject or if the SqlSmoObject does not have property visibility based on the Server version</exception>
public bool IsSupportedProperty(Type type, string propertyName, DatabaseEngineEdition databaseEngineEdition = DatabaseEngineEdition.Unknown)
and a generic version
public bool IsSupportedProperty<T>(string propertyName, DatabaseEngineEdition databaseEngineEdition = DatabaseEngineEdition.Unknown) where T : SqlSmoObject
Alternatively, SetDefaultInitFields/ClearAndInitialize should ignore unsupported properties, so can be tried.