Opt-out of EF / Code-First Migrations and use raw SQL scripts instead

Hi,

We are currently using ServiceStack with OrmLite in our application. Some of the built-in ServiceStack features (such as Auth, APIKeysFeature, DatabaseJobFeature, etc.) default to using EF (Entity Framework) or OrmLite Code-First migration classes to automatically generate and maintain their required database tables.

However, our DBAs do not want our application to manage database schema updates at runtime or use code-first migrations for these tables. Instead, our team strictly relies on raw SQL scripts executed externally to manage and maintain all database schemas.

I currently enable all features from a template and get the DDLs from generated tables in SQL Server but I was wondering if there is another way.

When a feature like ApiKeysFeature has a new table definition for a new version, do you provide that information in the release note?

Thank you!

All plugins that require tables are created within their InitSchema() method, so you can just comment out that call in any plugin to prevent any schema changes:

var feature = appHost.GetPlugin<ApiKeysFeature>();
// feature.InitSchema(db);

But it’s rare for plugins to require schema changes (can’t recall a time when it was needed), it’s purpose has been to create the table if it doesn’t exist already.

Hi @mythz

Our SQL Server scripts creates the tables exactly how EF core would (DDL from template installation).
We use Always Encrypted and encrypt the ApiKey.Key. It works fine except with the INDEX. The issue we have is with the default column length nvarchar(4000) from ORMLite with string. It exceeds SQL Server 8000-byte row-type limit.
If I change the column size to something smaller, it works fine but… The API Key feature UI will still use nvarchar(4000) and fail to insert the key.

Operand type clash: nvarchar(4000) encrypted with (encryption_type = 'DETERMINISTIC', encryption_algorithm_name = 'AEAD_AES_256_CBC_HMAC_SHA_256', column_encryption_key_name = 'CEK_AlwaysEncrypted', column_encryption_key_database_name = 'ABC') is incompatible with nvarchar(128) encrypted with (encryption_type = 'DETERMINISTIC', encryption_algorithm_name = 'AEAD_AES_256_CBC_HMAC_SHA_256', column_encryption_key_name = 'CEK_AlwaysEncrypted', column_encryption_key_database_name = 'ABC') Statement(s) could not be prepared

I know I could change the OrmLiteConverter to set a lower size for string but then all the table fields will be affected…

Is there any customization possible I can use to fix my issue?

There’s no way to customize the DB behavior for a specific feature like API Keys. I’m unclear on your setup, i.e. what does EF has to do with API Keys? and where is this Exception is occurring, do you have a StackTrace?

In the UI from a 500 Server Error when calling …/AdminCreateApiKey (Create API Key)

AdminCreateApiKey API just does a standard OrmLite Insert and the ApiKey class doesn’t have any custom field sizes so it’s just using OrmLite’s defaults.

You can only customize the SqlServer StringConverter globally, e.g:

StringConverter converter = OrmLiteConfig.DialectProvider.GetStringConverter();
converter.UseUnicode = true;
converter.StringLength = 1000;

Thanks. Won’t do it for me but is there any way I can override that AdminCreateApiKey request with my own? I’d like to have my own handler and create the key using my own SP if possible.

The only way would be to maintain a local modified copy of ApiKeysFeature.cs and register that instead.