Home

Settings

Reversio can parse one or more settings file at a time; each settings file can contain one or more jobs. A job contains a sequence of steps, and some steps are grouped in flows. Each file is processed in order, and each job/step is processed in the order it appears in the file.

The root of a settings file looks like this:

{
  "Jobs": [
    {
      "Provider": "System.Data.SqlClient",
      "ConnectionString": "",
      "Steps": [
            ...
      ]
    },
    {
      "Provider": "System.Data.SqlClient",
      "ConnectionString": "",
      "Steps": [
            ...
      ]
    },
    ...
}

• The Provider is fixed, as Reversio currently supports only Sql Server as source
• The ConnectionString is used by the job to access its source: a job can access one and only one source

There are four types of step: Load, PocoGenerate, PocoWrite, and DbContext.

Order of execution

Steps in a job must comply with the following ordering rule:

((Load)+ PocoGenerate PocoWrite)+ DbContext*

You can Load entities from the source multiple times (assuming that each time you load different entities), then you can PocoGenerate them. This sequence is called Flow. When you generate the POCOs, the flow is closed and you can't load more entities in it until a PocoWrite is executed. After that, you can create a new flow as as a sequence of Load(s)-PocoGenerate-PocoWrite. All POCOs generated in each flow will feed the resulting DbContext. The DbContext step is always to be executed last. If you want to generate multiple DbContexts, you must generate each in a separated job.

Example step schemas:

• In most cases you just need the four steps in sequence: Load PocoGenerate PocoWrite DbContext
• If you want to generate your POCOs from different schemas to different folders, each schema becomes a separate flow: Load1 PocoGenerate1 PocoWrite1 Load2 PocoGenerate2 PocoWrite2 DbContext
• Applying different filter policies to different schemas or different entity types (e.g. Tables vs Views): LoadTables LoadViews PocoGenerate PocoWrite DbContext

Load

The load step must be executed first in a flow. It is the only step that actually interacts with the database and reads tables, views, constraints, and indices.

{
  "StepType": "Load",
  "EntityTypes": [ "Table", "View" ],
  "Schemas": [ "dbo" ],
  "Exclude": {
    "ExcludeExact": [],
    "ExcludeRegex": []
  }
}

• EntityTypes (mandatory): which entity to load; currently only Table and View are supported
• Schemas: list of schemas to read; if nothing is specified, no filter will be applied and all schemas will be read
• ExcludeExact: Will exclude objects with a name matching exactly the specified blacklist; the name can be in the form TableName or Schema.TableName
• ExcludeRegex: Will exclude every object whose name matches at least one of the specified blacklist regexes; only table names - and not schemas - are taken into account

PocoGenerate

This step generates the POCOs but does not write them out as files yet.

{
  "StepType": "PocoGenerate",
  "Namespace": "MyProject.Model",
  "ClassAccessModifier": "public",
  "ClassPartial": true,
  "VirtualNavigationProperties": false,
  "Usings": [],
  "Extends": [],
  "ClassNameReplace": [
    {
      "Regex": "",
      "ReplaceWith": ""
    },
  ],
  "ClassNameForcePascalCase": true,
  "PropertyNameReplace": [
    {
      "Regex": "_",
      "ReplaceWith": ""
    }
  ],
  "PropertyNameForcePascalCase": true,
  "PropertyNullableIfDefaultAndNotPk": false
}

• Namespace (mandatory): The namespace to assign to each POCO contained in the current flow
• ClassAccessModifier: can be blank, private, internal, or public
• ClassPartial: POCOs will be generated as partial classes, to allow for custom code injection
• VirtualNavigationProperties: All navigation properties will have the virtual keyword
• Usings: additional namespaces to be added in the using section
• Extends: all POCOs will extend/implement the specified class/interfaces
• ClassNameReplace: A list of custom policies to format class names by replacing/removing parts based on a regex matching
• ClassNameForcePascalCase: if true, Reversio will try to convert a class name to PascalCase where possible; this happens after the regex-based replaces; defaults as false
• PropertyNameReplace: Same as ClassNameReplace, but applies to property names
• PropertyNameForcePascalCase: Same as ClassNameForcePascalCase, but applies to property names
• PropertyNullableIfDefaultAndNotPk: If a column is nullable but has a default value, the corresponding property will be marked as Nullable where applicable; defaults as false

PocoWrite

This step writes the POCOs generated in the previous step to an output folder.

{
  "StepType": "PocoWrite",
  "OutputPath": "./Model",
  "CleanFolder": true,
  "Exclude": {
    "ExcludeExact": [],
    "ExcludeRegex": []
  }
}

• OutputPath (mandatory): Where to store the POCOs; must be a folder
• CleanFolder: If true, every .cs file in the output path will be deleted prior to execution; this prevents old, unused files to be carried over when a table gets renamed or deleted
• Exclude: Follows the same rules described for the Load step, but it's applied on POCOs: excluded POCOs won't be written in the output folder but will still appear on the DbContext; use this if you want a custom class to be used in the DbContext but you don't want Reversio to generate/overwrite an omonym; rules are applied to Table names, not POCO names

DbContext

This step writes the DbContext.

{
  "StepType": "DbContext",
  "OutputPath": "./Model/MyDbContext.cs",
  "StubOutputPath": "./Model/MyDbContext.Stubs.cs",
  "Namespace": "MyProject.Model",
  "ClassName": "MyDbContext",
  "ClassAbstract": false,
  "Extends": [ "DbContext" ],
  "IncludeOnModelCreatingStub": "Signature",
  "IncludeIndices": true,
  "IncludeViews": true,
  "IncludeTablesWithoutPK": true
}

• OutputPath (mandatory): Must be a file path and not a folder; DbContext will be generated here
• StubOutputPath: Must be a file path and not a folder; if specified, in this location will be generated a partial class containing stubs as virtual/abstract methods, a stub for each entity; you can then override just the methods you are interested in; if the StubOutputPath equals the OutputPath, the stubs will be generated in the same class file where the DbSets are
• Namespace (mandatory): Namespace to assign to the DbContext class
• ClassName (mandatory): DbContext class name
• ClassAbstract: If true, DbContext will be an abstract class and all its stubs will be abstract as well; defaults as false
• Extends: the DbContext will extend/implement the specified class/interfaces (e.g. DbContext, IdentityContext, etc.)
• IncludeOnModelCreatingStub: defaults as ""
• • "Call": At the end of the OnModelCreating() method, a OnModelCreatingNext() method stub call will be made; you must define the method yourself in a custom partial class or subclass in order to correctly compile your code
• • "Signature": Same as above, but the method signature will be generated in the stubs locations (see StubOutputPath)
• • "": OnModelCreatingNext() won't be called or generated
• IncludeIndices: indices will be included where applicable in the form of HasIndex() calls; default as false
• IncludeViews: if true, views will be included as Query Types, in the form of DbQuery properties; defaults as false
• IncludeTablesWithoutPK: EF can't use tables without PK as Entities, but can use them as Query Types; if this setting is true, the DbContext will have a DbQuery property for each table without PK, but also for each of them an appropriate stub will be generated: the user must specify how to access the table through custom code; defaults as false