Adds a SqliteDialect alongside PostgresDialect, gated by mutually exclusive
postgres (default) / sqlite Cargo features, plus a feature-selected
ActiveDatabase type alias used throughout the public Georm/Defaultable
traits. Basic CRUD and Defaultable are fully covered by a new SQLite test
suite (tests/sqlite/*) running against a real SQLite database, alongside
split migrations/sqlite/*.
Two real dialect differences surfaced beyond placeholder syntax:
- SQLite's INTEGER columns type-infer as i64 in sqlx's compile-time query
macros (unlike Postgres SERIAL -> i32), so the SQLite test models use i64
for integer PK/FK fields.
- sqlx's SQLite query macros need bind arguments bound to a place rather
than passed as an inline expression (fixed once, centrally, in
SqlDialect::generate_relation_lookup).
Composite-key entities with chrono::DateTime columns (tests/composite_key.rs)
are not yet ported to SQLite: SQLite has no TIMESTAMPTZ equivalent, so sqlx
infers TEXT date/time columns as String rather than DateTime<Utc> unless the
query explicitly overrides the column type. That needs per-field type
overrides threaded through the generated queries, left as follow-up.
CI now matrixes over both backends; formatting/audit only run once since
they don't vary by backend. examples/postgres/* stays out of
--no-default-features builds by scoping sqlite lint/test just recipes to
`-p georm` (it depends on georm's default postgres feature via Cargo
feature unification, so building it under --features sqlite at the
workspace level double-activates both dialects).
Currently, all methods declared in the Georm trait are available.
If a struct has an ID pointing towards another entity, the user can
create a get method to get the entity pointed at from the database
too (local one-to-one relationship).
I still need to implement remote one-to-one relationships (one-to-one
relationships when the ID of the remote object is not available
locally).
I still need to also test and debug one-to-many relationships (ID of
the remote entiies not available locally) and many-to-many
relationships (declared in a dedicated table).
For now, IDs in all cases are simple types recognized by SQLx that are
not arrays. Options are only supported when explicitely specified for
one-to-one relationships.
Claude
phundrak
