pydal2sql
is a command line interface (CLI) tool that translates pydal define_table
Table definitions into SQL
statements. It supports different SQL dialects including SQLite, Postgres and MySQL. The tool generates
both CREATE TABLE
and ALTER TABLE
SQL statements. It does this using pydal's own logic.
Note: this package is only a Typer-based CLI front-end. The actual logic lives at robinvandernoord/pydal2sql-core
!
pip install pydal2sql
# or
pipx install pydal2sql
The following commands are supported:
pydal2sql create [file-name]
: Translate the file into SQL statements.pydal2sql create [file-name]@[git-branch-or-commit-hash]
: Translate a specific version of the file into SQL statements.pydal2sql create [file-name]@latest
: Translate the latest version of the file in git into SQL statements.pydal2sql create [file-name]@current
: Translate the current version of the file on disk into SQL statements.pydal2sql create
orpydal2sql create -
: Prompts the user to input the table definitions via stdin.
Bash pipe or redirect is also supported:
cat [file-name] | pydal2sql create
pydal2sql create < [file-name]
The tool allows you to specify a git branch or commit hash when translating a file. Using the 'latest' keyword will use the latest commit, and 'current' will use the file as it currently is on disk.
--table
,--tables
,-t
: Specify which database tables to generate CREATE statements for (default is all).--db-type
,--dialect
: Specify the SQL dialect to use (SQLite, Postgres, MySQL). The default is guessed from the code or else the user is queried.--magic
: If variables are missing, this flag will insert variables with that name so the code does (probably) not crash.--noop
: Doesn't create the migration code but only shows the Python code that would run to create it.
pydal2sql alter [file1] [file2]
: Generates the ALTER migration from the state in file1 to the state in file2.pydal2sql alter [file1]@[branch-or-commit-hash] [file2]@[branch-or-commit-hash]
: Compares the files at those specific versions and generates the ALTER migration.
Using -
instead of a file name will prompt the user via stdin to paste the define tables code.
Global options that go before the subcommand:
--verbosity
: Sets how verbose the program should be, with a number between 1 and 4 (default is 2).--config
: Path to a specific config toml file. Default is pyproject.toml at the key [tool.pydal2sql].--version
: Prints the CLI tool version and exits.--show-config
: Prints the currently used config and exits.
Example:
pydal2sql --verbosity 3 create
pydal2sql --version
A configuration file (in toml) can be selected with --config
. By default, pyproject.toml
is used.
In the configuration file, the following keys are supported under the [tool.pydal2sql] section:
dialect
/db-type
: Default database dialect to use.magic
: A boolean flag to use the--magic
option (default is False).noop
: A boolean flag to use the--noop
option (default is False).tables
: A list of table names to generate CREATE/ALTER statements for.
The CLI command options can overwrite the config values. For example, --no-magic
will still set magic to False even if
it's set to True in the config file.
Example of the toml configuration:
[tool.pydal2sql]
dialect = "postgres" # postgres, mysql or sqlite
magic = true
noop = false
tables = ["table1", "table2"]
All keys are optional.
If you're copy-pasting some define_table
statements which have validators or defaults that are defined elsewhere,
the SQL generation could crash due to msising variables. However, if these variables are irrelevant to the samentics of
the table definition (i.e. only used at runtime, not for the schema definition), you can now try the --magic
flag.
This flag will replace all missing variables with a special Empty
class, which does nothing but
prevent NameError
, AttributeError
and TypeError
s.
Magic
will also remove local imports and imports that could not be found.
This is of course not production-safe, so it shouldn't be used anywhere else.
The following patterns are currently not supported:
def define_tables(db): ...
pydal2sql
also exposes a generate_sql
method that can perform the same actions on one (for CREATE) or two (for
ALTER) pydal.Table
objects when used within Python.
from pydal import DAL, Field
from pydal2sql import generate_sql
db = DAL(None, migrate=False) # <- without running database or with a different type of database
person_initial = db.define_table(
"person",
Field(
"name",
"string",
notnull=True,
),
Field("age", "integer", default=18),
Field("float", "decimal(2,3)"),
Field("nicknames", "list:string"),
Field("obj", "json"),
)
print(
generate_sql(
db.person, db_type="psql" # or sqlite, or mysql; Optional with fallback to currently using database type.
)
)
CREATE TABLE person
(
id INTEGER PRIMARY KEY AUTOINCREMENT,
name VARCHAR(512),
age INTEGER,
float NUMERIC(2, 3),
nicknames TEXT,
obj TEXT
);
person_new = db.define_table(
"person",
Field(
"name",
"text",
),
Field("birthday", "datetime"),
redefine=True
)
generate_sql(
person_initial,
person_new,
db_type="psql"
)
ALTER TABLE person ADD "name__tmp" TEXT;
UPDATE person SET "name__tmp"=name;
ALTER TABLE person DROP COLUMN name;
ALTER TABLE person ADD name TEXT;
UPDATE person SET name="name__tmp";
ALTER TABLE person DROP COLUMN "name__tmp";
ALTER TABLE person ADD birthday TIMESTAMP;
ALTER TABLE person DROP COLUMN age;
ALTER TABLE person DROP COLUMN float;
ALTER TABLE person DROP COLUMN nicknames;
ALTER TABLE person DROP COLUMN obj;
pydal2sql
is distributed under the terms of the MIT license.