TypeDAL 2.0.1

Typing support for PyDAL

TypeDAL

Typing support for PyDAL. This package aims to improve the typing support for PyDAL. By using classes instead of the define_table method, type hinting the result of queries can improve the experience while developing. In the background, the queries are still generated and executed by pydal itself, this package only proves some logic to properly pass calls from class methods to the underlying db.define_table pydal Tables.

• TypeDAL is the replacement class for DAL that manages the code on top of DAL.
• TypedTable must be the parent class of any custom Tables you define (e.g. class SomeTable(TypedTable))
• TypedField can be used instead of Python native types when extra settings (such as default) are required ( e.g. name = TypedField(str, default="John Doe"))
• TypedRows: can be used as the return type of .select() and subscribed with the actual table class, so e.g. rows: TypedRows[SomeTable]. If you're lazy, list[SomeTable] works fine too but that misses hinting possibilities such as .first().

Version 2.0 also introduces more ORM-like funcionality. Most notably, a Typed Query Builder that sees your table classes as models with relationships to each other. See 3. Building Queries for more details.

Quick Overview

Below you'll find a quick overview of translation from pydal to TypeDAL. For more info, see the docs.

Translations from pydal to typedal

Description	pydal	typedal	typedal alternative(s)	...
Setup	from pydal import DAL, Field db = DAL(...)	from typedal import TypeDAL, TypedTable, TypedField db = TypeDAL(...)
Table Definitions	db.define_table("table_name", Field("fieldname", "string", required=True), Field("otherfield", "float"), Field("yet_another", "text", default="Something") )	@db.define class TableName(TypedTable): fieldname: str otherfield: float | None yet_another = TypedField(str, type="text", default="something", required=False)	import typing class TableName(TypedTable): fieldname: TypedField[str] otherfield: TypedField[typing.Optional[float]] yet_another = TextField(default="something", required=False) db.define(TableName)
Insert	db.table_name.insert(fieldname="value")	TableName.insert(fieldname="value")	# the old syntax is also still supported: db.table_name.insert(fieldname="value")
(quick) Select	# all: all_rows = db(db.table_name).select() # -> Any (Rows) # some: rows = db((db.table_name.id > 5) & (db.table_name.id < 50)).select(db.table_name.id) # one: row = db.table_name(id=1) # -> Any (Row)	# all: all_rows = TableName.collect() # or .all() # some: # order of select and where is interchangable here rows = TableName.select(Tablename.id).where(TableName.id > 5).where(TableName.id < 50).collect() # one: row = TableName(id=1) # or .where(...).first()	# you can also still use the old syntax and type hint on top of it; # all: all_rows: TypedRows[TableName] = db(db.table_name).select() # some: rows: TypedRows[TableName] = db((db.table_name.id > 5) & (db.table_name.id < 50)).select(db.table_name.id) # one: row: TableName = db.table_name(id=1)

All Types

See 2. Defining Tables

Roadmap

This section contains a non-exhaustive list of planned features for future feature releases:

• 2.1
  • Caching: adding a .cache() operation to the query builder which loads a repeated execution from cache (via pickling of the final object). Optionally, dependency tracking could be added to automatically expire cache items when one of the underlying objects have changed in the database.
• 2.2
  • Migrations: currently, you can use pydal's automatic migrations or disable those and manage them yourself, but adding something like edwh-migrate with pydal2sql as an option could make this project more production-friendly.

Caveats

• This package depends heavily on the current implementation of annotations (which are computed when the class is defined). PEP 563 (Postponed Evaluation of Annotations, accepted) aims to change this behavior ( and from __future__ import annotations already does) in a way that this module currently can not handle: all annotations are converted to string representations. This makes it very hard to re-evaluate the annotation into the original type, since the variable scope is lost (and thus references to variables or other classes are ambiguous or simply impossible to find).
• TypedField limitations; Since pydal implements some magic methods to perform queries, some features of typing will not work on a typed field: typing.Optional or a union (Field() | None) will result in errors. The only way to make a typedfield optional right now, would be to set required=False as an argument yourself. This is also a reason why typing.get_type_hints is not a solution for the first caveat.