You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
and a generic version
Alternatively,
SetDefaultInitFields/ClearAndInitialize
should ignore unsupported properties, so can be tried.The text was updated successfully, but these errors were encountered: