On an Apple M1, Microsoft's mcr.microsoft.com/mssql/server fails because the sqlcmd is not supported on ARM64; however, Microsoft makes an mcr.microsoft.com/azure-sql-edge Azure SQL Edge container that does work and claims to be fully T-SQL compatible (see here).
I managed to build my own provider that re-uses the MSSQLServerContainer, but with a different image:
/**
* Uses a {@link MSSQLServerContainer} with a `mcr.microsoft.com/azure-sql-edge` image (default: "latest") in place of
* the standard ` mcr.microsoft.com/mssql/server` image
*/
class AzureSqlEdgeContainerProvider extends JdbcDatabaseContainerProvider {
private static final String NAME = 'azuresqledge'
@Override boolean supports(String databaseType) {
return databaseType.equals(NAME);
}
@Override JdbcDatabaseContainer newInstance() {
return newInstance('latest');
}
@Override JdbcDatabaseContainer newInstance(String tag) {
def taggedImageName = DockerImageName.parse("mcr.microsoft.com/azure-sql-edge")
.withTag(tag)
.asCompatibleSubstituteFor("mcr.microsoft.com/mssql/server") // From MSSQLServerContainer.DEFAULT_IMAGE_NAME
return new MSSQLServerContainer(taggedImageName);
}
}I had to use a different databaseType name (azuresqledge instead of sqlserver) to prevent the two providers from competing. Perhaps there's a better way to avoid that competition without having to change the databaseType name.
Or perhaps there's a way to modify MSSQLServerContainer/...Provider to accept either image name.
Nonetheless, the above provider works fine with my limited, local testing thus far.
On an Apple M1, Microsoft's
mcr.microsoft.com/mssql/serverfails because thesqlcmdis not supported on ARM64; however, Microsoft makes anmcr.microsoft.com/azure-sql-edgeAzure SQL Edge container that does work and claims to be fully T-SQL compatible (see here).I managed to build my own provider that re-uses the
MSSQLServerContainer, but with a different image:I had to use a different
databaseTypename (azuresqledgeinstead ofsqlserver) to prevent the two providers from competing. Perhaps there's a better way to avoid that competition without having to change thedatabaseTypename.Or perhaps there's a way to modify
MSSQLServerContainer/...Providerto accept either image name.Nonetheless, the above provider works fine with my limited, local testing thus far.