Diesel vs SeaORM: Rustにおけるコンパイル時ORMsと動的ORMsの使い分け

はじめに

Rustの活況を呈するエコシステムにおいて、堅牢でパフォーマンスの高いWebサービスやデータ駆動型アプリケーションを構築するには、信頼性の高いオブジェクトリレーショナルマッピング（ORM）ソリューションがしばしば必要となります。ORMは、直接的なSQL操作の複雑さを抽象化し、開発者がデータベースエンティティをネイティブなRust構造体として扱えるようにします。しかし、Rustのエコシステムでは、ORM設計に関していくつかの異なる哲学が存在します。コンパイル時の安全性を優先するものと、より動的な柔軟性を提供するものです。この記事では、2つの著名なRust ORMであるDieselとSeaORMに焦点を当て、それらのコア設計原則を探り、Dieselのコンパイル時アプローチとSeaORMの動的な機能を対比させ、最終的に次のRustプロジェクトに最適なORMの選択をガイドします。これらの違いを理解することは、単なる学術的な演習ではありません。実際のアプリケーションにおける開発速度、保守性、実行時パフォーマンスに具体的な影響を与えます。

状況の理解

DieselとSeaORMの具体例に入る前に、RustにおけるORMに関連するいくつかのコア用語を簡単に定義しましょう。

• ORM（Object-Relational Mapping）： オブジェクト指向プログラミング言語を使用して、互換性のない型システム間でデータを変換するプログラミングテクニック。Rustでは、これはデータベーステーブルと行をRust構造体とインスタンスにマッピングすることを意味します。
• コンパイル時安全性： Rustコンパイラが、データベース操作に関連するエラー（例：間違った列名、不正確なデータ型）を、アプリケーションが実行される前に、コンパイル中に検出できる能力。これにはしばしば広範なマクロの使用が含まれます。
• 動的クエリ生成： ランタイムでデータベースクエリを構築する能力。多くの場合、特定のシナリオでより柔軟で冗長でないコードを可能にしますが、一部のコンパイル時チェックを犠牲にする可能性があります。
• Active Recordパターン： ORMに見られるアーキテクチャパターンで、テーブルはクラスまたは構造体にラップされ、データに対する操作（save、update、deleteなど）をオブジェクト上で直接実行できます。
• Data Mapperパターン： オブジェクトとデータベース間でデータを転送するマッパー（またはDAO - Data Access Object）のレイヤーがあるアーキテクチャパターンで、それらを互いに独立させます。

Diesel：コンパイル時の守護者

Dieselは、Rustエコシステムで最も成熟し、広く採用されているORMと言えるでしょう。その主な強みは、Rustの強力なマクロシステムを活用して、コンパイル中にクエリ、テーブルスキーマ、データ型を検証することによる、コンパイル時安全性へのコミットメントにあります。このアプローチは、実行時のデータベースエラーの可能性を大幅に減らし、アプリケーションをより堅牢にします。

原則と実装：

Dieselは、コードがコンパイルされれば、データベース操作は正しい可能性が高いという原則に基づいて動作します。これは、データベーススキーマを表すRust構造体を生成することによって達成されます。これらの構造体は、型安全なクエリビルダーAPIを使用してクエリを構築するために使用されます。

単純なpostsテーブルを考えてみましょう：

CREATE TABLE posts (
    id SERIAL PRIMARY KEY,
    title VARCHAR NOT NULL,
    body TEXT NOT NULL,
    published BOOLEAN NOT NULL DEFAULT FALSE
);

Dieselでは、schema.rsファイル（通常はdiesel print-schemaで生成されます）にスキーマを定義します。

// src/schema.rs
diesel::table! {
    posts (id) {
        id -> Int4,
        title -> Varchar,
        body -> Text,
        published -> Bool,
    }
}

そしてRust構造体：

// src/models.rs
use diesel::prelude::*;
use serde::{Deserialize, Serialize};

#[derive(Queryable, Selectable, Debug, PartialEq, Serialize, Deserialize)]
#[diesel(table_name = crate::schema::posts)]
pub struct Post {
    pub id: i32,
    pub title: String,
    pub body: String,
    pub published: bool,
}

#[derive(Insertable, Debug, Serialize, Deserialize)]
#[diesel(table_name = crate::schema::posts)]
pub struct NewPost {
    pub title: String,
    pub body: String,
}

ここで、挿入とクエリを実行してみましょう。

// src/main.rs (excerpt)
use diesel::prelude::*;
use diesel::pg::PgConnection;
use dotenvy::dotenv;
use std::env;

mod schema;
mod models;

use models::{Post, NewPost};
use schema::posts::dsl::*;

fn establish_connection() -> PgConnection {
    dotenv().ok();
    let database_url = env::var("DATABASE_URL").expect("DATABASE_URL must be set");
    PgConnection::establish(&database_url)
        .unwrap_or_else(|_| panic!("Error connecting to {}", database_url))
}

fn main() {
    let mut connection = establish_connection();

    // 新しい投稿を挿入
    let new_post = NewPost {
        title: "My First Post".to_string(),
        body: "This is the content of my first post.".to_string(),
    };
    let inserted_post: Post = diesel::insert_into(posts)
        .values(&new_post)
        .get_result(&mut connection)
        .expect("Error saving new post");
    println!("Saved post: {:?}", inserted_post);

    // 公開済みの投稿をクエリ
    let published_posts = posts
        .filter(published.eq(true))
        .limit(5)
        .select(Post::as_select())
        .load::<Post>(&mut connection)
        .expect("Error loading published posts");
    println!("Published posts: {:?}", published_posts);
}

posts、published、titleなどはすべてschema.rsから派生した型チェックされた要素であることに注意してください。存在しない列をクエリしようとしたり、不正確な型を渡そうとしたりすると、Dieselはコンパイル時にそれを検出します。

アプリケーションシナリオ：

• 高信頼性アプリケーション： 実行時エラーを最小限に抑える必要がある場合。
• 安定したデータベーススキーマを持つアプリケーション： スキーマの変更はschema.rsの再生成と、場合によってはRustコードの更新を必要とします。
• 厳格な型安全性を優先するチーム： データベース操作にも拡張されたRustの強力な型システムから利益を得ます。

SeaORM：動的な柔軟主義者

Dieselとは対照的に、SeaORMは、Active RecordとData Mapperパターンからインスピレーションを得た、より動的なアプローチを採用しています。非同期、スキーマに依存しない、高度に composable なORMとして自負しています。クエリ構造自体のコンパイル時検証の提供は少ないですが、ランタイムでクエリを構築するための強力で流暢なAPIと、データがロードされた後の強力な型安全性を提供します。

原則と実装：

SeaORMは、複雑で動的なクエリの構築において、柔軟性と簡潔さを目指しています。クエリ構築のためにschema.rsに大きく依存するのではなく、エンティティがRust構造体として定義され、クエリがデータベース操作にマッピングされる流暢なAPIを使用して構築される、コードファーストまたはエンティティファーストのアプローチを使用します。非ブロックデータベース操作のために、async/awaitを多用しています。

SeaORMでpostsテーブルを再度見てみましょう。

// src/entities/post.rs
use sea_orm::entity::prelude::*;
use serde::{Deserialize, Serialize};

#[derive(Clone, Debug, PartialEq, Eq, DeriveEntityModel, Serialize, Deserialize)]
#[sea_orm(table_name = "posts")]
pub struct Model {
    #[sea_orm(primary_key)]
    pub id: i32,
    pub title: String,
    pub body: String,
    pub published: bool,
}

#[derive(Copy, Clone, Debug, EnumIter, DeriveRelation)]
pub enum Relation {}

impl ActiveModelBehavior for ActiveModel {}

ここで、挿入とクエリを実行してみましょう。

// src/main.rs (excerpt)
use sea_orm::{
    ActiveModelTrait,
    Database,
    EntityTrait,
    IntoActiveModel,
    Set,
};
use dotenvy::dotenv;
use std::env;

mod entities; // あなたの投稿エンティティを含む
use entities::post;

#[tokio::main]
async fn main() -> Result<(), sea_orm::DbErr> {
    dotenv().ok();
    let database_url = env::var("DATABASE_URL").expect("DATABASE_URL must be set");
    let db = Database::connect(&database_url).await?;

    // 新しい投稿を挿入
    let new_post = post::ActiveModel {
        title: Set("My SeaORM Post".to_string()),
        body: Set("Content of my SeaORM post.".to_string()),
        published: Set(false), // 明示的に設定
        ..Default::default() // 他のフィールドはデフォルト値で埋める
    };
    let res = new_post.insert(&db).await?;
    println!("Saved post: {:?}", res);

    // 公開済みの投稿をクエリ
    let published_posts: Vec<post::Model> = post::Entity::find()
        .filter(post::Column::Published.eq(true))
        .limit(5)
        .all(&db)
        .await?;
    println!("Published posts: {:?}", published_posts);

    Ok(())
}

SeaORMは、列を参照するためにpost::Column::Publishedを使用します。これはモデル内の列が存在することに関して型安全ですが、Dieselほど厳密にクエリ文字列自体をコンパイル時に検証するわけではありません。しかし、その流暢なAPIは、複雑な結合やサブクエリを非常に読みやすく、 composable なものにします。非同期性も、最新のWebサービスにとって重要な利点です。

アプリケーションシナリオ：

• 非同期Webサービス： 非ブロックI/OのためにRustのasync/awaitを活用します。
• 急速に進化するスキーマを持つアプリケーション： schema.rsへの結合度が低いため、一部の開発ワークフローではスキーマの変更がより円滑になります。
• 高度に composable で動的なクエリを望む場合： その流暢なAPIは、プログラムで複雑なクエリを構築することに優れています。
• より「Rustらしい」感覚を好む場合： クエリ検証のために外部マクロにそれほど依存しない。

ORMの選択

DieselとSeaORMの選択は、主にプロジェクトの優先事項とチームの好みに帰着します。

• 最大限のコンパイル時安全性と堅牢で、あまり動的でないクエリのニーズのために： Dieselは優れた選択肢です。成熟しており、十分に文書化されており、実行時エラーが発生する前に多くのデータベース関連のエラーを検出します。データベーススキーマが比較的安定しており、コンパイル時保証が最重要である場合、Dieselは強力な候補です。
• 非同期操作、動的なクエリ構築、およびより「コードファースト」のアプローチのために： SeaORMが輝きます。そのasync性質は、高並行サービスに最適であり、その柔軟なAPIは、開発者がランタイムで複雑なクエリをエレガントに構築することを可能にします。より動的なクエリパターンを予期するか、asyncネイティブソリューションを好む場合、SeaORMはおそらくより良い選択です。

どちらのORMもRustエコシステム内で強力なソリューションを提供します。Dieselのコンパイル時検証への重点は比類なき安全性を提供し、SeaORMは最新の非同期機能と動的なクエリ構築を提供します。

結論

DieselとSeaORMはどちらもRustでのデータベース操作のための説得力のあるソリューションを提供し、それぞれが設計哲学に基づいた独自のニッチを切り開いています。Dieselはコンパイル時安全性を推進し、実行時エラーを減らす堅牢な保証を提供します。一方、SeaORMは非同期操作と動的なクエリの柔軟性を優先し、最新のWebサービスアーキテクチャに対応します。最終的に、あなたのRustプロジェクトに最適なORMは、鉄壁のコンパイル時チェック（Diesel）を重視するか、柔軟でasyncネイティブなクエリ構築（SeaORM）を重視するかにかかっています。