Documentation is missing information on how to set up database users and rights

Setting up a fresh database installation (using Entity Framework Core EnsureCreated()), I need to create a number of database users and grant appropriate rights to them for all objects that ModelBuilder is creating (e.g. entities, sequences etc., but also user permissions, like CREATE SESSION system privilege).

My goal is to end up with a single DBA user for later database migration and a less privileged application user for running the app.

I’ve been looking for corresponding ModelBuilder extension methods, but couldn’t find any.

As far as I can see, documentation lacks information on how to create database users and grant privileges using EF Core Code-first.

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: 1b15cd4c-9cba-c0e2-7618-7d621a3c5936
• Version Independent ID: f4681bc6-57be-6e69-cad9-776ce64d93bd
• Content: Overview of Entity Framework Core - EF Core
• Content Source: entity-framework/core/index.md
• Product: entity-framework
• Technology: entity-framework-core
• GitHub Login: @ajcvickers
• Microsoft Alias: avickers

[roji]

Portability across database systems.

This is the crux of the matter - and unfortunately it simply doesn’t seem to be true; while at a superficial glance, databases indeed have users and users can be granted privileges, when looking deeper there are some important differences.

As an example, compare SQL Server CREATE USER, PostgreSQL CREATE USER and Oracle CREATE USER. The various options are quite different, since the database capabilities around user, role and privilege management are different; that’s the unfortunate reality of world of databases. In contrast, SQL query syntax and behavior are better standardized and generally tend to be similar across databases (although with important exceptions).

To summarize:

• If we provide a limited common denominator covering multiple databases (assuming a useful one actually exists!), any user needing database-specific functionality would still be stuck with using raw SQL.
• We could cover the entire realm of possibilities for each database, but that’s a lot of effort for each database.
• In general, correctly modeling all user/privilege management in EF Core - with all the options etc. - would be a substantial amount of work.
• I do agree there’s some value in an EF user/privilege management API - .NET APIs instead of raw SQL does mean a bit more safety and less room for errors. But given the investment required and database diversity, that value simply seems far too low to make sense.

So, I created an abstract EF database context by reverse-engineering, building all common entities and properties. Then I derived provider specific contexts, adding provider specific features, like changing data types.

I understand this isn’t a perfect experience, but that seems quite orthogonal to the issue being discussed above. If you need to manage users and privileges, these need to be specified in any case - the question in this issue is whether that’s done in raw SQL or via an EF API.

[roji]

Triage decision: this isn’t something we plan to implement in EF Core - there’s not enough common ground across databases, and the value is generally limited given that raw SQL can be used (and given the investment required).

Of course, something may be doable in a nuget package, although unlike EFCore.CheckConstraints, support for this would probably need to interact with other parts of EF Core which aren’t necessarily easily extensible to plugins (e.g. the migrations SQL provider).