JobServer constructor shouldn't run a SQL query

the JobServer class requires initializing its parent's Databases collection to construct itself:

 internal JobServer(Server parentsrv, ObjectKeyBase key, SqlSmoState state) : 
            base(key, state)
        {
            // even though we called with the parent collection of the column, we will 
            // place the JobServer under the right collection
            singletonParent = parentsrv as Server;
            
            // WATCH OUT! we are setting the m_server value here, because JobServer does
            // not live in a collection, but directly under the Database
            SetServerObject( parentsrv.GetServerObject());
            m_comparer = parentsrv.Databases["msdb"].StringComparer;
            jobCategories = null;
            alertCategories = null;
            operatorCategories = null;
            alertSystem = null;
            alerts = null;
            operators = null;
            targetServers = null;
            targetServerGroups = null;
            jobs = null;
            sharedSchedules = null;
        }

1. It shouldn't be making a SQL query of any kind in the constructor anyway
2. Populating the databases collection is hugely expensive
3. SqlSmoObject has a way to delay load StringComparer already that doesn't populate the collection, this object may just need a little refactoring of that method to support specifying msdb as the database to use for the query.

I found this by accident while trying to write a test for something else.
This code blows up because Databases["msdb"] doesn't exist:

var smoFilter = "[contains(@Name, 'SmoBaseline')]";
db.Parent.Databases.ClearAndInitialize($"[@Name='{Urn.EscapeString(db.Name)}']", Enumerable.Empty<string>());
db.Parent.Logins.ClearAndInitialize(smoFilter, Enumerable.Empty<string>());
db.Parent.LinkedServers.ClearAndInitialize(smoFilter, Enumerable.Empty<string>());
if (db.Parent.IsSupportedObject<JobServer>())
{
    db.Parent.JobServer.Jobs.ClearAndInitialize(smoFilter, Enumerable.Empty<string>());
}

Beginnen Sie mit dem im Issue gezeigten JobServer-Konstruktor und prüfen Sie, wie parentsrv.Databases["msdb"] StringComparer erhält. Vergleichen Sie dies mit dem vorhandenen verzögerten Laden von StringComparer in SqlSmoObject und verwenden Sie anschließend das bereitgestellte ClearAndInitialize-Testszenario, um zu überprüfen, dass die Konstruktion von JobServer Databases nicht befüllt und nicht fehlschlägt, wenn msdb fehlt.