Commit Graph

12 Commits

Author SHA1 Message Date
Claude 4c314c2f0b feat: add SQLite support behind a sqlite Cargo feature
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).
2026-07-21 19:06:35 +00:00
phundrak 3307aa679d feat: Add generated and generated_always attributes
This commit introduces support for PostgreSQL generated columns by
adding two new field attributes to the `Georm` derive macro:
`#[georm(generated)]` and `#[georm(generated_always)]`.

The `#[georm(generated_always)]` attribute is for fields that are
always generated by the database, such as `GENERATED ALWAYS AS
IDENTITY` columns or columns with a `GENERATED ALWAYS AS (expression)
STORED` clause. These fields are now excluded from `INSERT` and
`UPDATE` statements, preventing accidental writes and ensuring data
integrity at compile time.

The `#[georm(generated)]` attribute is for fields that have a default
value generated by the database but can also be manually overridden,
such as `GENERATED BY DEFAULT AS IDENTITY` columns. These fields
behave similarly to `#[georm(defaultable)]` fields, allowing them to
be omitted from `INSERT` statements to use the database-generated
value.

For now, the behaviour is the same between `#[georm(generated)]` and
`#[georm(defaultable)]`, but the addition of the former now will be
useful for future features.

Key changes:
- Added `generated` and `generated_always` attributes to
  `GeormFieldAttributes`.
- Introduced `GeneratedType` enum in the IR to represent the different
  generation strategies.
- Modified the `create` and `update` query generation to exclude
  fields marked with `#[georm(generated_always)]`.
- Integrated `#[georm(generated)]` fields with the existing
  defaultable struct logic.
- Added validation to prevent conflicting attribute usage, namely
  `#[georm(generated)]` and `#[georm(generated_always)]` on the same
  field.

Implements #3
2025-08-09 15:28:37 +02:00
phundrak 13c7a413d7 chore: bump to 0.2.1 2025-06-10 12:16:06 +02:00
phundrak fcd0f57857 chore: bump version to 0.2.0 2025-06-10 12:04:58 +02:00
phundrak 19284665e6 feat: implement preliminary composite primary key support
Add support for entities with composite primary keys using multiple
#[georm(id)] fields. Automatically generates {EntityName}Id structs for
type-safe composite key handling.

Features:
- Multi-field primary key detection and ID struct generation
- Full CRUD operations (find, create, update, delete, create_or_update)
- Proper SQL generation with AND clauses for composite keys
- Updated documNtation in README and lib.rs

Note: Relationships not yet supported for composite key entities
2025-06-09 22:41:39 +02:00
phundrak 190c4d7b1d feat(examples): add PostgreSQL example with user relationship
Adds an example demonstrating user, comment, and follower relationship
including:
- User management with profiles
- Comments (not really useful, just for showcasing)
- Follower/follozing relationships
- Ineractive CLI interface with CRUD operations
- Database migrations for the example schema
2025-06-09 21:30:35 +02:00
phundrak 0c3d5e6262 feat: upgrade to Rust 1.86 and edition 2024
Upgrades rust toolchain from 1.84 to 1.86, switches to Rust edition
2024, and updates dependencies including SQLx to 0.8.6.
2025-06-09 21:26:19 +02:00
phundrak 8217a28a28 fix(deps): update tokio to 1.45.1 to address RUSTSEC-2025-0023
Updates tokio dependency to address security advisory RUSTSEC-2025-0023.
This ensures the codebase uses a secure version of the tokio runtime.
2025-06-07 15:46:10 +02:00
phundrak ab2d80d2f6 chore: migrate development environment from Nix flakes to devenv
Replace Nix flake-based development setup with devenv for better
developer experience and more streamlined environment management.

Changes:
  - Remove flake.nix and flake.lock files
  - Add devenv.nix, devenv.yaml, and devenv.lock configuration
  - Update .envrc to use devenv instead of nix develop
  - Remove Docker development setup (compose.dev.yml, docker/mod.just)
  - Expand .gitignore with comprehensive IDE and OS exclusions
  - Remove Docker-related just commands from justfile
2025-06-07 15:46:10 +02:00
phundrak aafbfb7964 feat: add foreign one_to_one relationships 2025-06-07 15:42:31 +02:00
phundrak bca0619f30 fix: simple ORM for one struct and foreign references work
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.
2025-01-31 23:14:39 +01:00
phundrak 96ac2aa979 chore: migrate source code from old repo to this repo 2025-01-26 15:18:31 +01:00