State of play with Rust ORMs and Migration managers

1. &
Rust ORM
Migrations

2. 2
ORM: Benefits
●
Database vendor abstraction
– Developers don’t need to know
the intricacies of the database
●
Multiple database support
●
Auto-generation of migrations
Rust ORM

3. 3
ORM: Benefits
●
Column safety
●
Type safety
●
Foundation of MVC, and any
other architectural pattern
that has a “model”
Rust ORM

4. 4
ORM: Negatives
●
Another leaky abstraction
●
Another dependency
– Bugs, nuances, security issues
●
Another thing to learn
Rust ORM

5. 5
ORM: Gold standard
●
Django - 107 years of effort (COCOMO) – 17 years
old
●
Ruby on Rails – 104 years of effort - 18 years old
– Grails (Groovy) – 205 years of effort – 18 years old
●
Meteor-js - 59 years of effort – 11 years old
●
Symfony - 284 years of effort – 17 years old
●
Hibernate – 230 years of effort – 21 years old

6. 6
ORM: Older products
●
Drupal - 22 years old
●
ASP.NET – 20 years old
●
J2EE
– c.f. Hibernate
– Enterprise JavaBeans – 25 years old
●
WebObjects – 1996-2008 – 12 years

7. 7
Rust ORM: schema crate
●
Create a separate crate with the schema
– OpenAPI/JSONSchema definitions
– Rust struct’s generated by progenitor, including
serialisation/deserialisation functionality
●
Due to Rust’s trait impl coherence rules,
database persistence needs to be added to
these structs
●
Generate for other languages such as
TypeScript

8. 8
Rust ORM: Must have
●
DQL & DML
– Insert, for all data-types used in the schema
– Update, …
– Query, …
●
Actively maintained
●
Transaction support

9. 9
Rust ORM: Nice to have
●
Upsert
– More efficient than alt.: query+insert+update
●
PostgreSQL support
●
Sqlite support
– Very handy for light-weight tests
●
DDL/Migration management
– Another tool can be used for this

10. 10
Rust ORMs: Popular (>1k*)
●
Diesel - 18 years of effort – 8 years old
●
Sea-ORM – 9 years of effort – 2 years old
●
Rbatis – 7 years of effort – 3 years old
Rust database framework
●
sqlx - 2 years of effort – 10 years old

11. 11
Rust ORMs: Obscure
●
Ormx – 1 year of effort – 2.5 years old
●
Rustorm – 2 years of effort – 5 years old - abandoned
●
toql - 5 years of effort – 3 years old
●
Summer-mybatis – 4 years of effort – 1 year old
●
butane - 2 years of effort – 3.5 years old
●
sprattus – 1 years of effort – 2 years old
●
Yukino-dev - 2 years of effort – 2 years old
●
Ormlite – 1 year of effort – 1 year old
●
Tql - 2 years of effort - 7 years old
NoSQL ORMs
●
wither (mongo) - 1 year of effort – 5 years old

12. 12
Rust ORM: diesel
use diesel::prelude::*;
#[derive(Queryable)]
pub struct Post {
pub id: i32,
pub title: String,
pub body: String,
pub published: bool,
}
Add derives … looks simple

13. 13
Rust ORM: diesel
diesel::table! {
posts (id) {
id -> Int4,
title -> Varchar,
body -> Text,
published -> Bool,
}
}
Except diesel needs a “schema.rs” that
defines the database fields for one database
Maybe can be generated by diesel API, and injected
using progenitor’s “post” hook.

14. 14
Rust ORM: Sea-ORM
#[derive(Clone, Debug, PartialEq, Eq, DeriveEntityModel,
Deserialize, Serialize)]
#[sea_orm(table_name = "posts")]
pub struct Model {
#[sea_orm(primary_key)]
#[serde(skip_deserializing)]
pub id: i32,
pub title: String,
#[sea_orm(column_type = "Text")]
pub text: String,
}
#[derive(Copy, Clone, Debug, EnumIter, DeriveRelation)]
pub enum Relation {}
impl ActiveModelBehavior for ActiveModel {}
Every model must be called Model

15. 15
Rust ORM: butane
#[model]
#[derive(Clone, Debug, Default, Deserialize, PartialEq,
Serialize, ToSchema)]
pub struct Blog {
#[serde(default)]
pub posts: Many<Post>,
#[pk]
pub blog_id: uuid::Uuid,
#[serde(default, skip_serializing_if = "Option::is_none")]
pub slug: Option<String>,
}
Requires primary keys, and relations
Vec → Many

16. 16
Migrations: Benefits
●
Rollback
Migrations

17. 17
Migrations: Benefits
●
Rollback
Migrations: Negatives
●
More effort than deleting and
installing schema each deploy...
i.e. there are no negatives
Migrations

18. 18
Migrations: Must have
●
Schema version stored in
each database instance
Migrations

19. 19
Migrations: Must have after v1
●
Migration batch support
– After v1 of any project, new versions
of a product will be released at
intervals that include many schema
changes that were part of different
pull requests
Migrations

20. 20
Migrations: Nice to have
●
Per-change undo
– Mostly used by developers when:
●
Switching branches
●
Developing migrations
– Developers can manually undo
changes
Migrations

21. 21
Migrations: Nice to have
●
Rollback
– Alternative is use backup and
restore
Migrations

22. 22
Migrations: Nice to have
●
Zero-downtime migrations
– Avoid locking
– Schema changes have three phases
1) Additive changes
2) Update services
3) Either
1) Rollback if services stable, or
2) Destructive changes to the schema
Migrations

23. 23
Migrations: Nice to have
●
ORM integration
– Allows database vendor agnostic
migrations
– Allows auto-generating migrations
from model changes
Migrations

24. 24
Rust Migration
●
Reshape - 2 year of effort – 1 year old
– Ticks most boxes, except no ORM integration, and PG only
●
prisma-engines – 65 year of effort – 3 years old
– TypeScript CLI
●
Refinery
– lacks undo features

25. 25
TypeScript Migration
●
prisma – 29 years of effort – 2 years old
●
knex - 20 years of effort – 10 years old
●
Typeorm - 50 years of effort – 6 years old

26. 26
Go Migration
●
Altas – 24 years of effort – 2 years old
●
bytebase - 41 years of effort – 2 years old