microsoft/healthcare-shared-components

Shared packages used across Microsoft's health care services

Health Care Shared Components

This repository is a collection of components used by the Microsoft Health Care team which develops services such as the FHIR Server for Azure, the IoMT FHIR Connector for Azure, and the Medical Imaging Server for DICOM.

Contributing

This project welcomes contributions and suggestions. Most contributions require you to agree to a Contributor License Agreement (CLA) declaring that you have the right to, and actually do, grant us the rights to use your contribution. For details, visit https://cla.opensource.microsoft.com.

When you submit a pull request, a CLA bot will automatically determine whether you need to provide a CLA and decorate the PR appropriately (e.g., status check, comment). Simply follow the instructions provided by the bot. You will only need to do this once across all repos using our CLA.

This project has adopted the Microsoft Open Source Code of Conduct. For more information see the Code of Conduct FAQ or contact [email protected] with any additional questions or comments.

Privacy

Microsoft values your privacy. See the Microsoft Privacy Statement for more information

healthcare-shared-components's Issues

Refactor `SchemaManager`

The SchemaManager tool under \tools could be improved in a few ways:

• The namespace should begin with Microsoft.Health, not SchemaManager
• There are SchemaManager and SchemaManager.Core projects that aren't used for different purposes
• Dependencies are manually registered in Program.cs rather than using the registration methods in Microsoft.Health.SqlServer.Registration.
• SchemaManager dependency registration isn't tested

We should avoid creating `HttpClient`

We should consider injecting IHttpClientFactory instead: https://docs.microsoft.com/en-us/dotnet/architecture/microservices/implement-resilient-applications/use-httpclientfactory-to-implement-resilient-http-requests

healthcare-shared-components/src/Microsoft.Health.SqlServer/Features/Schema/Manager/SchemaClient.cs

Line 25 in 1e0dc85

_httpClient = new HttpClient();

Eliminate need to insert into SchemaVersion table at start of "full" migration script

We should be able to eliminate this from the start of every 6.sql, 7.sql, etc file:

/*************************************************************
    Schema Version
**************************************************************/

INSERT INTO dbo.SchemaVersion
VALUES
    (6, 'started')

GO

Instead, we could insert the row before calling the script, like we do for .diff.sql scripts.

BaseSchema.sql missing some stored procedures

Describe the bug
The BaseSchema.sql script is missing stored procedures for UpsertSchemaVersion and SelectCurrentSchemaVersion.

Expected behavior
The required base schema is installed

Actual behavior

Error from SQL database on upserting InstanceSchema information
System.Data.SqlClient.SqlException (0x80131904): Could not find stored procedure 'dbo.UpsertInstanceSchema'.
   at System.Data.SqlClient.SqlConnection.OnError(SqlException exception, Boolean breakConnection, Action`1 wrapCloseInAction)
   at System.Data.SqlClient.SqlInternalConnection.OnError(SqlException exception, Boolean breakConnection, Action`1 wrapCloseInAction)
   at System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj, Boolean callerHasConnectionLock, Boolean asyncClose)
   at System.Data.SqlClient.TdsParser.TryRun(RunBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj, Boolean& dataReady)
   at System.Data.SqlClient.SqlDataReader.TryConsumeMetaData()
   at System.Data.SqlClient.SqlDataReader.get_MetaData()
   at System.Data.SqlClient.SqlCommand.FinishExecuteReader(SqlDataReader ds, RunBehavior runBehavior, String resetOptionsString)
   at System.Data.SqlClient.SqlCommand.CompleteAsyncExecuteReader()
   at System.Data.SqlClient.SqlCommand.InternalEndExecuteReader(IAsyncResult asyncResult, String endMethod)
   at System.Data.SqlClient.SqlCommand.EndExecuteReaderInternal(IAsyncResult asyncResult)

Set value for varbinary column would not clean old value

Describe the bug
Set value for varbinary column would not clean old value, if the old value length is longer than new value there would be invalid bytes after new value. For the method "ToDataRecordEnumerable", the SqlDataRecord is used by multiple rows, and varbinary value is wrong.

To Reproduce
Steps to reproduce the behavior:

1. TableValuedParameterDefinition add parameters with 2 rows contains varbinary column
2. Row 1 varbinary: 0x1111, row 2 varbinary: 0x22
3. after add parameters, the 2nd row varbinary value become 0x2211

Expected behavior
Row 2 should have correct value and length short than row 1

Actual behavior
Row 2 value become 0x2211

Dependency Dashboard

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

• Update dependency Microsoft.Azure.Functions.Worker.Sdk to v1.17.2

Detected dependencies

github-actions

.github/actions/compute-version/action.yml

• gittools/actions v1.1.1
• gittools/actions v1.1.1

.github/actions/dotnet-publish/action.yml

• actions/upload-artifact v4
• azure/CLI v2
• actions/setup-dotnet v4
• microsoft/action-publish-symbols v2.1.6

.github/workflows/codeql-analysis.yml

• actions/checkout v4
• actions/setup-dotnet v4
• github/codeql-action v3
• github/codeql-action v3

.github/workflows/packages-ci.yml

• actions/checkout v4
• actions/setup-dotnet v4
• azure/login v2

.github/workflows/packages-pr.yml

• actions/checkout v4
• actions/setup-dotnet v4

nuget

Directory.Packages.props

• xunit.runner.visualstudio 2.8.1
• xunit.extensibility.core 2.8.1
• Xunit.DependencyInjection 9.3.0
• xunit.assert 2.8.1
• xunit 2.8.1
• System.Linq.Async 6.0.1
• System.CommandLine.Rendering 0.2.0-alpha.19174.3
• System.CommandLine.Experimental 0.2.0-alpha.19174.3
• System.CommandLine.DragonFruit 0.2.0-alpha.19174.3
• Polly.Contrib.WaitAndRetry 1.1.1
• Polly 8.4.1
• NSubstitute 5.1.0
• Newtonsoft.Json.Schema 4.0.1
• Newtonsoft.Json 13.0.3
• Microsoft.SqlServer.SqlManagementObjects 171.30.0
• Microsoft.SqlServer.DacFx 162.3.566
• Microsoft.SourceLink.GitHub 8.0.0
• Microsoft.NET.Test.Sdk 17.10.0
• Microsoft.NET.Sdk.Functions 4.4.0
• Microsoft.IO.RecyclableMemoryStream 3.0.1
• Microsoft.IdentityModel.Tokens 7.6.2
• Microsoft.IdentityModel.Protocols.OpenIdConnect 7.6.2
• Microsoft.IdentityModel.JsonWebTokens 7.6.2
• Microsoft.Extensions.Azure 1.7.4
• Microsoft.DurableTask.Client.OrchestrationServiceClientShim 1.0.5
• Microsoft.DurableTask.Client 1.2.4
• Microsoft.DurableTask.Abstractions 1.2.4
• Microsoft.Data.SqlClient 5.2.1
• Microsoft.CodeAnalysis.CSharp.Workspaces 4.10.0
• Microsoft.CodeAnalysis.CSharp 4.10.0
• Microsoft.CodeAnalysis.Common 4.10.0
• Microsoft.Build.Utilities.Core 17.10.4
• Microsoft.Build.Framework 17.10.4
• Microsoft.Azure.WebJobs.Host.Storage 5.0.0
• Microsoft.Azure.WebJobs.Extensions.DurableTask 2.13.4
• Microsoft.Azure.WebJobs.Extensions 5.0.0
• Microsoft.Azure.WebJobs.Core 3.0.39
• Microsoft.Azure.WebJobs 3.0.39
• Microsoft.Azure.Functions.Worker.Sdk 1.17.1
• Microsoft.Azure.Functions.Worker.Extensions.Timer 4.3.1
• Microsoft.Azure.Functions.Worker.Extensions.Http.AspNetCore 1.3.2
• Microsoft.Azure.Functions.Worker.Extensions.Http 3.2.0
• Microsoft.Azure.Functions.Worker.Extensions.DurableTask 1.1.4
• Microsoft.Azure.Functions.Worker 1.22.0
• Microsoft.Azure.Functions.Extensions 1.1.0
• Microsoft.Azure.DurableTask.Core 2.17.1
• Microsoft.ApplicationInsights 2.22.0
• MartinCostello.Logging.XUnit 0.4.0
• IdentityServer4.Storage 4.1.2
• IdentityServer4 4.1.2
• Google.Protobuf 3.27.2
• Ensure.That 10.1.0
• DistributedLock.SqlServer 1.0.5
• coverlet.collector 6.0.2
• Azure.Storage.Common 12.19.0
• Azure.Storage.Blobs 12.20.0
• Azure.Security.KeyVault.Keys 4.6.0
• Azure.Messaging.EventGrid 4.24.0
• Azure.Identity 1.12.0
• Azure.Core 1.40.0

global.json

• dotnet-sdk 8.0.302

---

• Check this box to trigger a request for Renovate to run again on this repository

SqlServer initilization doesn't push schema on newly created database.

Describe the bug
I had to specify sqlSchemaAutomaticUpdatesEnabled to populate database with scripts on new database. Overwise database is empty.
To Reproduce
Steps to reproduce the behavior:

1. Set database name which doesn't exist.
2. Set AllowDatabaseCreation to true.
3. Run SchemaInitializer - you will have database, but it would be empty.

Expected behavior
I expect to have all tables and SP in newly created database.

Actual behavior
Empty database.

Workaround
I have to manually specify sqlSchemaAutomaticUpdatesEnabled to true to populate DB.