Settings.GenerateSingleDbContext

Settings.GenerateSingleDbContext and the multi-context settings

Switches from generating one DbContext to generating many, each seeing only the tables and columns it is allowed to.

Setting	Type	Default
Settings.GenerateSingleDbContext	bool	true
Settings.MultiContextSettingsConnectionString	string	""
Settings.MultiContextSettingsPlugin	string	""
Settings.MultiContextAttributeDelimiter	char	'~'

What it does

With GenerateSingleDbContext = true - the default - you get one DbContext covering everything the filters let through, and FilterSettings decides what that is.

Set it false and the whole model changes. The generator reads a set of MultiContext.* tables in your database that describe, per context: which tables it contains, which columns of those tables, what to call them, and what namespace to put them in. One pass over the schema produces as many contexts as those tables describe - dozens, if you want.

FilterSettings is not used at all in this mode. The database is the configuration.

Why you would want it

The use case is a service architecture where each API should reach only the data it needs. One DbContext per service, each a genuinely narrow view of the same database, all generated from one schema read and one set of rules that live where the DBAs can see them.

Doing that with one .tt per service means duplicating the schema read and keeping a dozen filter blocks in step by hand. This moves the rules into the database.

The settings

MultiContextSettingsConnectionString points at the database holding the MultiContext.* tables. Leave it empty to read them from the same database you are reverse engineering. Set it when the configuration lives somewhere separate - which is usually the better arrangement, because the settings are yours and the schema may not be.

MultiContextAttributeDelimiter is the character separating several attributes in one settings column:

UPDATE MultiContext.[Column]
SET Attributes = '[ExampleForTesting("abc")]~[CustomRequired]'
WHERE Name = 'Dollar';

MultiContextSettingsPlugin replaces the built-in reader with one of your own:

Settings.MultiContextSettingsPlugin = "c:\\Path\\YourReader.dll,Full.Namespace.YourReaderClass";

An assembly path and a type name, comma-separated. Setting it also stops the efrpg tool being asked to read the MultiContext.* tables, since your plugin is supplying the settings instead.

Setting it up

1. Run the MultiContextSettings.sql script to create the tables.
2. Populate them - one row per context, per table, per column.
3. In Database.tt:

Settings.GenerateSingleDbContext = false;
Settings.GenerateSeparateFiles   = false;   // See the gotchas
Settings.AddUnitTestingDbContext = false;

Generating Multiple Database Contexts in a Single Go has the full walkthrough.

Gotchas

SQL Server only. The multi-context settings reader has no implementation for the other four databases.

Set GenerateSeparateFiles = false when contexts share table names, which they usually do - that is the point. With separate files on, two contexts both containing Customer write to Customer.cs and the second overwrites the first.

The MultiContext schema is always excluded from generation. The default SchemaFilter drops it, so your settings tables never turn up as entities. A schema of your own named MultiContext will also disappear.

FilterSettings silently does nothing in this mode. Leaving your filter block in place is harmless and misleading - it looks like it is still in charge.

Turning it off later is a large change, because your service projects now depend on context names and namespaces that came from the database.

Custom columns on the settings tables need the MultiContextAllFields*Processing callbacks to be read.

See also

• Generating Multiple Database Contexts in a Single Go - the full setup
• Settings.MultiContextAllFields*Processing - reading your own columns
• Filtering - what this replaces
• Settings.GenerateSeparateFiles
• Settings Reference