Add 'LedgerViewType' as supported property for SQL 2022 and Azure DBs

[cheenamalhotra]

PR fixes issue microsoft/azuredatastudio#21541 and microsoft/azuredatastudio#21171
It seems we're hitting these warnings for every single view element in OE, and we end up making a new query for every view.

sqltools Verbose: 0 : Smo property name LedgerViewType for Smo type Microsoft.SqlServer.Management.Smo.View is not added as supported properties. This can cause the performance of loading the OE nodes
sqltools Verbose: 0 : Smo property name LedgerViewType for Smo type Microsoft.SqlServer.Management.Smo.View is not added as supported properties. This can cause the performance of loading the OE nodes
MicrosoftSqlToolsServiceLayer Warning: 0 : Missing regular property LedgerViewType property bag state Lazy for type View
MicrosoftSqlToolsServiceLayer Information: 0 : get data for urn: Server[@Name='<server>']/Database[@Name='<database>']/View[@Name='<viewname>' and @Schema='dbo']

Adding LedgerViewType as supported property for Azure SQL and SQL 2022, as I see other Ledger Types are added similar way.
Local testing seems to fix the issue.

@shueybubbles @nofield would appreciate your feedback :)

[shueybubbles]

why can't OE pick up the property list from here instead of requiring the C# code override?

[shueybubbles]

If someone has cycles to optimize this a bit, I recommend:

1. 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?

2. 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
   

[shueybubbles]

even better - we updated SetDefaultInitFields/ClearAndInitialize to ignore unsupported properties already. Give it a try.

---

In reply to: 1374521242

[cheenamalhotra]

Thanks for the feedback @shueybubbles !
I honestly have limited experience in this area so I'm not sure how to redesign this in limited time, but I've opened issue #1802 for anyone willing to jump on it.

@kburtram @aasimkhan30 @nofield I think it would be best for you to take a decision on how/when to improve the OE design, as area owners. As of the issue with Views listing in OE, it is related to the Ledger Type, and the change in PR fixes it, but I'll leave that to you to decide if you would like to go for complete fix or this change for upcoming release.

Also, I couldn't find any other missing property that is leading to performance degradation at the moment.

[kburtram]

LGTM, please see which of David's feedback can be applied incrementally to this PR and which are larger refactoring. The refactorings can be picked up separately by the OE committers.

[cheenamalhotra]

I don't think much can be done as of current design incrementally in this PR. We should prioritize #1802 sometime soon, will follow up for any undertakings.