This is an fork project from https://github.com/agronholm/sqlacodegen
This is a tool that reads the structure of an existing database and generates the appropriate SQLAlchemy model code, using the declarative style if possible.
This tool was written as a replacement for sqlautocode, which was suffering from several issues (including, but not limited to, incompatibility with Python 3 and the latest SQLAlchemy version).
- Supports SQLAlchemy 2.0
- Produces declarative code that almost looks like it was hand written
- Produces PEP 8 compliant code
- Accurately determines relationships, including many-to-many, one-to-one
- Automatically detects joined table inheritance
- Excellent test coverage
To install, do:
pip install sqlacodegen_v2
To include support for the PostgreSQL CITEXT
extension type (which should be
considered as tested only under a few environments) specify the citext
extra:
pip install sqlacodegen_v2[citext]
At the minimum, you have to give sqlacodegen a database URL. The URL is passed directly to SQLAlchemy's create_engine() method so please refer to SQLAlchemy's documentation for instructions on how to construct a proper URL.
Examples:
sqlacodegen_v2 postgresql:///some_local_db sqlacodegen_v2 --generator tables mysql+pymysql://user:password@localhost/dbname sqlacodegen_v2 --generator dataclasses sqlite:///database.db
To see the list of generic options:
sqlacodegen_v2 --help
The selection of a generator determines the
The following built-in generators are available:
tables
(only generatesTable
objects, for those who don't want to use the ORM)declarative
(the default; generates classes inheriting fromdeclarative_base()
declarative-dataclasses
(generate declarative model with SuperclassMappedAsDataclass
)dataclasses
(generates dataclass-based models; v1.4+ only)sqlmodels
(generates model classes for SQLModel)
The following options can be turned on by passing them using --option
(can be used
multiple times):
tables
noconstraints
: ignore constraints (foreign key, unique etc.)nocomments
: ignore table/column commentsnoindexes
: ignore indexes
declarative
- all the options from
tables
use_inflect
: use theinflect
library when naming classes and relationships (turning plural names into singular; see below for details)nojoined
: don't try to detect joined-class inheritance (see below for details)nobidi
: generate relationships in a unidirectional fashion, so only the many-to-one or first side of many-to-many relationships gets a relationship attribute, as on v2.X
- all the options from
dataclasses
- all the options from
declarative
- all the options from
sqlmodel
- all the options from
declarative
- all the options from
The code generators that generate classes try to generate model classes whenever
possible. There are two circumstances in which a Table
is generated instead:
- the table has no primary key constraint (which is required by SQLAlchemy for every model class)
- the table is an association table between two other tables (see below for the specifics)
By default, table names are converted to valid PEP 8 compliant class names by replacing
all characters unsuitable for Python identifiers with _
. Then, each valid parts
(separated by underscores) are title cased and then joined together, eliminating the
underscores. So, example_name
becomes ExampleName
.
If the use_inflect
option is used, the table name (which is assumed to be in
English) is converted to singular form using the "inflect" library. For example,
sales_invoices
becomes SalesInvoice
. Since table names are not always in
English, and the inflection process is far from perfect, inflection is disabled by
default.
Relationships are detected based on existing foreign key constraints as follows:
- many-to-one: a foreign key constraint exists on the table
- one-to-one: same as many-to-one, but a unique constraint exists on the column(s) involved
- many-to-many: (not implemented on the
sqlmodel
generator) an association table is found to exist between two tables
A table is considered an association table if it satisfies all of the following conditions:
- has exactly two foreign key constraints
- all its columns are involved in said constraints
Relationships are typically named based on the table name of the opposite class.
For example, if a class has a relationship to another class with the table named
companies
, the relationship would be named companies
(unless the use_inflect
option was enabled, in which case it would be named company
in the case of a
many-to-one or one-to-one relationship).
A special case for single column many-to-one and one-to-one relationships, however, is
if the column is named like employer_id
. Then the relationship is named employer
due to that _id
suffix.
For self referential relationships, the reverse side of the relationship will be named
with the _reverse
suffix appended to it.
If the built-in generators with all their options don't quite do what you want, you can
customize the logic by subclassing one of the existing code generator classes. Override
whichever methods you need, and then add an entry point in the
sqlacodegen.generators
namespace that points to your new class. Once the entry point
is in place (you typically have to install the project with pip install
), you can
use --generator <yourentrypoint>
to invoke your custom code generator.
For examples, you can look at sqlacodegen's own entry points in its pyproject.toml.
You may import generate_models
directly from sqlacodegen_v2