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
Replace the existing two-query create_or_update implementation with a
single atomic PostgreSQL upsert using ON CONFLICT clause to eliminate
race conditions and improve performance.
Race condition fix:
The previous implementation had a critical race condition where
multiple concurrent requests could:
1. Both call find() and get None (record doesn't exist)
2. Both call create() and the second one fails with duplicate key
error
3. Or between find() and create(), another transaction inserts the
record
This created unreliable behavior in high-concurrency scenarios.
Changes:
- Add generate_upsert_query function in trait_implementation.rs
- Generate SQL with INSERT ... ON CONFLICT ... DO UPDATE SET pattern
- Remove default trait implementation that used separate
find/create/update calls
- Update derive_trait to include upsert query generation
- Convert create_or_update from default implementation to required
trait method
The new implementation eliminates race conditions while reducing
database round trips from 2-3 queries down to 1, significantly
improving both reliability and performance.
Introduces support for `#[georm(defaultable)]` attribute on entity
fields. When fields are marked as defaultable, generates companion
`<Entity>Default` structs where defaultable fields become `Option<T>`,
enabling easier entity creation when some fields have database defaults
or are auto-generated.
Key features:
- Generates `<Entity>Default` structs with optional defaultable fields
- Implements `Defaultable<Id, Entity>` trait with async `create` method
- Validates that `Option<T>` fields cannot be marked as defaultable
- Preserves field visibility in generated companion structs
- Only generates companion struct when defaultable fields are present
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.
