StaticInstanceThe registered source for this process, resolved once through the class factory.
Cached because IsSystemUser sits behind permission checks that run per entity and per user; resolving (and allocating) on every call would be needless churn. Registrations happen as module-load side effects of importing a data-provider package, which always precedes any permission evaluation, so caching cannot capture a stale answer in practice. Tests that register a source after first use should call ResetInstance.
Resolves the system user from UserCache when it is warm, and otherwise reads it (with
its roles) from vwUsers/vwUserRoles on the given provider's connection. Returns null —
never throws — when the provider can't run SQL, the row is absent, or the query fails, so
callers degrade rather than crash.
The synchronous half of the contract: identity recognition, no I/O. Consumed by permission checks in shared code (field-level security, notably) that cannot await, and by anything else that needs to know "is this the platform's own account?" without fetching it.
StaticResetDrops the cached Instance so the next access re-resolves through the class factory. Intended for tests that register a source after the cache was populated.
The server-side WellKnownUserSource: resolves MJ's built-in accounts straight out of the core-schema user views.
Why this lives here rather than in the dialect packages. Both
SQLServerDataProviderandPostgreSQLDataProviderdepend on this package, and this package depends on neither, so one registration here serves both dialects — the implementations would otherwise be identical. Any process holding a database provider has necessarily loaded this module, which makes "the registration exists" line up exactly with "this process has a Database provider". A registration in a server package like MJServer would instead leave every CLI and job process (MJCLI, CodeGen, MetadataSync, AICLI) silently without a system user.Cache first, query as the cold-start fallback. UserCache now lives in this same package, so reading it here is a plain in-process lookup rather than the inverted dependency it used to be. The query remains, and is load-bearing rather than vestigial:
Refreshhas run. A cold cache is the normal state for a process that resolves a system user during its own bootstrap, which is exactly when BaseEngine asks.UserCacheis a process-global singleton, so in a multi-connection host its contents are not necessarily thisprovider's users.Deliberately not memoized privately: a long-lived copy would drift from
UserCacheafter a role sync, and that drift was the flaw in an earlier attempt at this. Reading the cache directly shares whatever every otherUserCacheconsumer sees, so there is no second copy to go stale.