Skip to content

Releases: m0n0x41d/explicit-sql

Fixing library imports

Choose a tag to compare

@m0n0x41d m0n0x41d released this 08 Apr 12:09
v0.0.5

Fixed library imports

explicit-sql v0.0.3 - First Public Alpha Release

Choose a tag to compare

@m0n0x41d m0n0x41d released this 08 Apr 11:14

Full Changelog: https://github.com/m0n0x41d/explicit-sql/commits/v0.0.2

A type-safe, explicit SQL query generator focused on clarity and developer experience, initially targeting DuckDB compatibility.
This first public alpha release provides the foundation for a human-mind-friendly SQL generator. The library aims to bridge the gap between raw SQL and full ORMs by offering type safety and declarative table definitions without the complexity of object-relational mapping.
Perfect for projects where type safety and explicit SQL generation are desired, especially with DuckDB, but where ORM overhead is unnecessary.

✨ Features
Type-safe Table Definitions: Define table structures using Python's TypedDict.
Declarative Configuration: Simple TableConfig for schema, primary keys, and naming.

SQL Generation:
CREATE TABLE IF NOT EXISTS statements reflecting TypedDict definitions.
INSERT statements from dictionaries.
UPDATE statements by primary key, with optional RETURNING clause.
DELETE statements by primary key.
DELETE statements using arbitrary WHERE conditions.
SELECT statements with specific columns (* supported), WHERE conditions, ORDER BY, and LIMIT.

Type Conversion: Sensible defaults for mapping Python types (int, str, float, bool, Optional, Literal) to common SQL types (INTEGER, TEXT, REAL, BOOLEAN).

Naming Conventions: Automatic conversion from Python camelCase or PascalCase field names to snake_case SQL column names.

⚠️ Current Limitations & Roadmap
Basic WHERE Clauses: Current WHERE clauses only support equality (=) checks combined with AND. More complex operators (<, >, LIKE, IN, OR, etc.) are planned.
Limited Type Support: Focuses on common scalar types. Support for more complex types (e.g., DATE, TIMESTAMP, JSON, SQL ENUMs) is planned.
No Relationship Handling: Does not automatically handle foreign keys or joins between tables.
Dialect Specificity: Primarily tested with DuckDB syntax; broader dialect compatibility (e.g., PostgreSQL, SQLite) might require future adjustments.