.NET Core tool for easy scaffolding of your PostgreSQL server.
Makes your .NET Core project to do a static type checking - on your PostgreSQL.
This tool will generate all the necessary source code files needed to make a simple execution of your PostgreSQL routines (functions or procedures):
-
Simple execution - or data retrieval - in C#, sync, or async.
-
All the necessary data-access code as connection object extension.
-
All related model classes (or Data Transfer Object) for data retrieval operations (function returning recordset or physical table returned from a function).
You can use this tool to enforce static type checking over PostgreSQL programable routines (functions or procedures) - in your .NET Core project.
Simply add the code generation command with this tool to your pre-build event.
Or, you can simply just generate the code you need with a simple command.
It will take care of things like:
-
PostgreSQL function overload for multiple versions.
-
PostgreSQL array types for complex input and output.
-
Superfast serialization to generated model classes without any caching. See serialization section.
.NET global tool install:
dotnet tool install --global dotnet-pgroutiner
You will receive a message:
You can invoke the tool using the following command: PgRoutiner Tool 'dotnet-pgroutiner' (version '1.0.0') was successfully installed.
Type (case-insensitive):
PgRoutiner
It is enough to just type PgRoutiner
(case-insensitive) - and it will look for .NET Core project file (.csproj
) in the current directory - and start source file generation by using first available connection string in your configuration.
Or - you may supply additional configuration settings either trough:
- Custom JSON configuration settings section
PgRoutiner
. It is your standardappsettings.json
orappsettings.Development.json
from your project. For example, to configure the connection that will be used:
{ "PgRoutiner": { "Connection": "MyConnection", } }
- Standard command-line interface, by supplying command-line arguments. Example from above, to configure the connection that will be used:
pgroutiner connection=MyConnection
The command-line settings if supplied - will always override JSON configuration settings.
Name | Description | Default |
---|---|---|
Connection | Connection string name from your configuration connection string to be used. | First available connection string. |
Project | Relative path to project .csproj file. |
First available .csproj file from the current dir. |
OutputDir | Relative path where generated source files will be saved. | Current dir. |
ModelDir | Relative path where model classes source files will be saved. | Default value saves model classes in the same file as a related data-access code. |
Schema | PostgreSQL schema name used to search for routines. | public |
Overwrite | Should existing generated source file be overwritten (true) or skipped if they exist (false) | true |
Namespace | Root namespace for generated source files. | Project root namespace. |
NotSimilarTo | NOT SIMILAR TO SQL regular expression used to search routine names. |
Default skips this matching. |
SimilarTo | SIMILAR TO SQL regular expression used to search routine names. |
Default skips this matching. |
SourceHeader | Insert the following content to the start of each generated source code file. | // <auto-generated at timestamp /> |
SyncMethod | Generate a sync method, true or false. |
True. |
AsyncMethod | Generate a async method, true or false. |
True. |
Mapping * | Key-values to override default type mapping. Key is PostgreSQL UDT type name and value is the corresponding C# type name. | See default mapping here |
- Key-values are JSON objects in JSON configuration. For command-line, use the following format:
pgroutiner mapping:Key=Value
- Simple
void
function example with usage - Function parameter overload example
- Returning value
- Returning anonymous recordset
- Returning table
Serialization and mapping are performed using Norm.net data access library.
It uses positional mapping instead of mapping by name.
This means that the mapping mechanism is a little bit faster than any standard mapping mechanism commonly used (like Dapper or EF).
For example, performance tests are indicating that serialization and mapping of 1 million rows that Dapper averages at 0:02.859
seconds and Norm.net positional mapping at 0:02.400
seconds. Norm.net does not use any additional caching to achieve performances because it doesn't need to.
However, the number of returning record fields is limited to 12, more than 12 it will fallback to standard mapping by name (which averaged at 0:03.022
seconds at performance tests). If you need more performances and use positional mapping with more than 12 record fields, open an issue with Norm.net and consider supporting this project and also Norm.net.
- Npgsql
- Norm.net >= 1.5.1.
- System.Linq.Async (only for async operations)
- .NET Core 3.0
- .NET Core 3.1
This is open-source software developed and maintained freely without any compensation whatsoever.
If you find it useful please consider rewarding me on my effort by buying me a beer🍻 or buying me a pizza🍕
Or if you prefer bitcoin: bitcoincash:qp93skpzyxtvw3l3lqqy7egwv8zrszn3wcfygeg0mv
Copyright (c) Vedran Bilopavlović - VB Consulting and VB Software 2020 This source code is licensed under the MIT license.