4.2. Generator settings

• Name conversion
• Custom arguments
  • Configuration example
  • Handling arguments in your script
• Partial generation

Each generator has settings stored in the project file.

All paths specified in the settings are relative to the project file. This allows the same settings to be used for the entire team, regardless of the team members' operating system and repository location.

Name conversion

OrmFactory can transform table and column names for passing to the generator. By default, it does not do this. This is necessary if the naming style in the database and in the code differs. This transformation affects only the ClassName and RepositoryName tags of Table element and FieldName tag of Column element. See the 4.3. Project structure section for details.

Also, OrmFactory will try to convert the repository name to plural, and the class name to singular.

Custom arguments

You can pass custom command-line arguments to your external scripts and tools (such as Python scripts or custom CLI applications). This gives you the flexibility to override namespaces, target specific DbContext names, or pass any custom flags directly from the OrmFactory GUI.

Key behaviors to keep in mind:

• Multi-line layout: You can organize your parameters vertically using Enter for better readability. All line breaks are automatically converted to single spaces when the generator is executed.
• Auto-trimming: Any leading tabs or spaces added by the XML serializer for code indentation are automatically stripped during project loading, ensuring your arguments remain intact.

For formatting convenience, line breaks will be replaced with spaces upon execution.

Configuration example

If you are using multiple generators to split your project into different database contexts (e.g., a core DataContext and an isolated AnalyticsDbContext using Partial generation settings), you can configure the same script with different arguments.

Generator 1 (Main Database):
Leave the arguments field empty to use your script's defaults, or specify explicitly:

--namespace "OrmFactoryCom.Model" --context "DataContext"

Generator 2 (Analytics Database):
Utilize the multi-line capability to format long strings clearly:

--output "../OrmFactoryCom/Model/ArchiveContextGenerated.cs"
--namespace "OrmFactoryCom.ArchiveModel"
--context "ArchiveDbContext"

When run, OrmFactory wraps the script path in quotes to handle any accidental spaces and seamlessly appends your custom options into a single command line:

python "scripts/generate_ef.py" --output "../OrmFactoryCom/Model/ArchiveContextGenerated.cs" --namespace "OrmFactoryCom.ArchiveModel" --context "ArchiveDbContext"

Handling arguments in your script

To catch and parse these custom arguments inside your Python generator, it is highly recommended to use the built-in argparse module.

Here is a clean, production-ready template for your script:

import sys
import argparse
import xml.etree.ElementTree as ET

def main():
    # 1. Setup the argument parser
    parser = argparse.ArgumentParser(description="OrmFactory Custom Generator")
    
    # 2. Define expected flags (with defaults for fallback)
    parser.add_argument("--output", default="../Model/Generated.cs", help="Path to output C# file")
    parser.add_argument("--namespace", default="OrmFactory.Model", help="Target C# namespace")
    parser.add_argument("--context", default="DataContext", help="DbContext class name")
    
    # 3. Parse the arguments sent by OrmFactory
    args = parser.parse_args()
    
    # Now you can use args.output, args.namespace, and args.context in your logic
    print(f"Generating context '{args.context}' in namespace '{args.namespace}'...")

    # 4. Read the project XML structure provided by OrmFactory via stdin
    xml_data = sys.stdin.read()
    root = ET.fromstring(xml_data)
    
    # Your generation logic goes here...

if __name__ == "__main__":
    main()

This setup ensures that your script remains flexible, backwards-compatible, and easy to test both from the OrmFactory GUI and directly via the terminal.

Partial generation

Partial generation is needed to limit the scope of the model that is passed to the generator. This is useful, for example, when you use several generators for different parts of the information system.

By default, the partial generation option is set to "Whole project".

Lower-level entities become accessible as you uncheck higher-level ones. If you uncheck "the whole project", you can select specific databases. Uncheck a database, you can select schemas, uncheck a schema - tables.

Selecting a schema or database allows you to avoid editing the generator configuration after each table addition.

Another possibility of partial generation is to use layouts as a list of tables to be passed to the generator. Simply select working layout options in the partial generation settings, after which adding tables to the layout will mean adding it to the generation process.