DEV Community: Mila K

Unions: delving into unsafe Rust

Mila K — Wed, 06 May 2026 14:49:27 +0000

I came across union while looking through the code of the client's library for the new trading platform WATS by the Warsaw Stock Exchange (GPW), which currently is (still) under development.

When I skimmed through the code, I noticed a lot of unsafe functions, that were the artifacts of using unions instead of structures or enums.

I never used or even encountered the unions before, so I wanted to learn about them. It proved to be an interesting journey, where I also revisited other Rust topics (like memory safety and ownership).

According to official documentation, union uses the same syntax as structure.

If I would describe it unofficially: it's like a child between struct and enum - it looks like structure, but behaves more like enum - but is neither of them.

struct FooStruct {
   x: i64,
   y: f64
}

union FooUnion {  // <---- union instead of struct
   x: i64,
   y: f64
}

In the code snippet above, we declare FooStruct, which is a structure with 2 fields: x for the integer value, and y for the float.
The FooUnion has identical fields, from reading the code, but under the hood, union can store only 1 value! Which value? Compiler does not know, this is why reading the value should be enclosed into unsafe block or function.
While Rust is generally very descriptive about value's mutability, here, actually, the writing to the field is safe. This is because we have only one place to write to, so as long as the variable has a mutable ownership of the value, it can be overwritten.

let mut my_union = FooUnion { y: 23.5 };
my_union.y = 25.7;

With union, what we're saying to the compiler is: FooUnion will store either integer or float in the single memory allocation, look away when we access it, as WE know how to handle it.
Thus, to declare it, we'll use:

let my_struct = FooStruct { x: 42, y: 23.5 };

// Union declares only one of its fields
let my_union = FooUnion { x: 42 };

This instantly reminds me of the enum - (remove the unsafe part) - there is only one value currently stored.

The natural train of my thoughts was: what about pattern matching? The Rust documentation conveniently provides the match statement:

let u = FooUnion { x: 10 };

unsafe {
    match u {
        FooUnion { x: 10 } => println!("Found exactly ten!"),
        FooUnion { y } => println!("Found y = {y} !"),
    }
}

However, if we rewrite the match into a statement used in an enum, we'll see a warning that the second arm is unreachable.

unsafe {
    match u {
        FooUnion { x } => println!("Found x = {x} !"),
        FooUnion { y } => println!("Found y = {y} !"), , // <-|
 //                           warning: unreachable pattern  --|
    }
}
// Alternatively, we can use std::mem::transmute to transform value
// unsafe{
//     let val = std::mem::transmute::<FooUnion, i32>(my_union);
//     println!("Found value = {val} !");
// }

(｢•-•)｢ ʷʱʸ? Because there is nothing to compare, we don't have a few variants to match against: we have 1 union with 1 field, whatever we'll write in the initialisation call.

let u = FooUnion { x: 10 };

// OR
let u = FooUnion { y: 23.5 };

The result from the match statement will be Found x = 10 ! if the value was "under" x, or we'll have Found x = 1102839808 ! (which is a 23.5 representation of the float value in Big Endian type) - which probably means nothing during run time.

Let's add the field that stores values on the Heap. The most obvious one is a String. If we include it into the fields of the union, it requires us to add std::mem::ManuallyDrop wrapper - which is a neat reminder that we need to drop the variable ourselves.

Accessing value (≖_≖ )

How do you know what is a stored value? I found myself accustomed to writing if statements that guarantee that the type is known, like if let Variant::A = var { ... }, however, I could not understand how to do it with union.
Apparently, you cannot: this is a real definition of unsafety.
This code would produce different outputs: first one is the length of the string, another one - is an actual string. In this case, compiler cannot help us to write the matching arms, it expects from us to KNOW the type that is stored under the variable.

pub union FooUnionHeap {
    x: i32,
    y: f32,
    z: std::mem::ManuallyDrop<String>,
}

let s = "HelloWorld".to_string();
let my_union_h = FooUnionHeap { z: ManuallyDrop::new(s) };


unsafe {
    match my_union_h {
        FooUnionHeap { x } => { println!("Found x = {x} !"); },

    };
}

// Output: `Found x = 10 !`

unsafe {
    match my_union_h {
        FooUnionHeap { z } => { 
            println!("Found z = {} !", z.to_string()) 
        },

    };
}

// Output: `Found z = HelloWorld !`

The same goes for just borrowing different fields:

let my_union = FooUnion { y: 25.7 };
unsafe {
    let a = &my_union.x;
    let b = &my_union.y;
    println!("a: {a}, b: {b}");
}
// Output: `a: 1103993242, b: 25.7`.

Size of the type (>.<)人(⸝⸝⸝>﹏<⸝⸝⸝)

The size of structure and union is different, because structure's size is roughly the sum of its fields (+ alignment), and for union - size of its largest field. However, the union has the same size in bytes as enum. Even after comparing both against the union with C representation (which can change the padding between fields), the size is the same.

pub struct FooStruct {
    x: i32,
    z: String,
}

pub enum FooEnum {
    X(i32),
    Z(String)
}

#[repr(C, packed)]
pub union FooUnionHeapC {
    pub x: i32,
    pub z: ManuallyDrop<String>,
}

pub union FooUnionHeap {
    x: i32,
    z: ManuallyDrop<String>,
}
println!("Size of heap allocated union: {}",
    std::mem::size_of::<FooUnionHeap>());
// Output: Size of heap allocated union: 24
println!("Size of heap allocated union with C representation: {}",
    std::mem::size_of::<FooUnionHeap>());
// Output: Size of heap allocated union with C representation: 24
println!("Size of enum: {}", std::mem::size_of::<FooEnum>());
// Output: Size of enum: 24
println!("Size of structure: {}", std::mem::size_of::<FooStruct>());
// Output: Size of structure: 32

Speed 三三ᕕ( ᐛ )ᕗ

Here, we compare only the enum and union using criterion tool.

Both creation and access of the union is faster - probably because both creation and access to the enum requires also to check the discriminant, which holds information about used variant.

The DANGER ( ꩜ ᯅ ꩜;)⁭

With great power comes great responsibility --- Amazing Fantasy, and more specifically
It is the programmer’s responsibility to make sure that the data is valid at the field’s type --- The Rust Reference

To see how everything compiles, but panics during runtime, we must manually drop the value first, and then access it to read.

// Drops the `z` field from the union
fn consume(u: &mut FooUnionHeap) {
    unsafe{ ManuallyDrop::drop(&mut u.z); }
}


fn outer() {
    let s = "HelloWorld".to_string();
    // owner of the union
    let mut my_union_h = FooUnionHeap { z: ManuallyDrop::new(s) };

    // union's `z` field is dropped here
    consume(&mut my_union_h);

    // reading the `z` field
    unsafe {
        match &my_union_h {
            FooUnionHeap { z } => { 
                println!("Found z = {} !", z.to_string()) 
            },
        }
    };
}

// The ERROR: unsafe precondition(s) violated:
// ptr::copy_nonoverlapping requires that both pointer arguments are
// aligned and non-null and the specified memory 
// ranges do not overlap

// This indicates a bug in the program. 
// This Undefined Behavior check is optional, and 
// cannot be relied on for safety.

The compiler looked away while we crashed due to the dangling pointers.

Why and when to use them? ᕙ(⇀‸↼‶)ᕗ

When unions were first introduced in Rust in 2015, the goal was to provide the native support for C-compatible unions (RFC).

For me, if not in FFI, they are the thieves of joy developing in Rust - you must know what to use when, and be sure it exists - manageable in small code bases, nightmare - in large.

Why it was chosen in WATS - I think speed or/and compatibility with some C API. After all, it is a trading platform.

The code is available on Github.

What do you think? (☞ ͡° ͜ʖ ͡°)☞

Real Q: Do you prefer to specialise in one/two languages? I sometimes hear the opinion, that "real" devs are not restricted by any language, but this could mean that they have a broader knowledge base rather than in-depth expertise. What do you think?

Mila K — Wed, 29 Apr 2026 15:09:51 +0000

Unit testing with SeaOrm

Mila K — Fri, 10 Apr 2026 13:58:30 +0000

A few weeks ago, I submitted my BSc thesis and project, where I developed the identity management application. The API was implemented in Rust, with Actix-Web framework, and SeaOrm for database communication.

The University's expectation was to create a Django backend and HTML+CSS frontend, and cover them with unit-tests. However when it came to mocking Postgres connection with SeaOrm, I quickly became confused.

The SeaOrm provides a MockDatabase (which is great!), but to use it we must fill it with query or execution results first. The documentation has an overview for the basic find and insert methods, others are scarcely mentioned in various StackOverflow answers.

This post describes the logic and code snippets, that I had to mock for my project: update / save, select partial model or a tuple, and delete cascade.

Let's assume we're building the application for the vet clinic for dogs, and the part of the database design includes the following relationships:

Update and Save

While save can update or insert, both functions expect to fill the query result with the models.
For example, when testing the following code:

pub async fn update_dog_chip(
    id: Uuid,
    chip_id: String,
    conn: &DatabaseConnection,
) -> Result<(), DbErr> {
    if let Some(dog) = dog::Entity::find_by_id(id).one(conn).await? {
        let mut active_model: dog::ActiveModel = dog.into();
        active_model.chip_id = ActiveValue::Set(chip_id);
        active_model.save(conn).await?;
        // Save here will default to update as the ID is already set
        // but the mocking logic is same
        // active.update(conn).await?;
    }
    Ok(())
}

To mock the database response to test this function, the connection should include two Dog models in separate arrays: one for results of the select query, and another one for save operation:

#[tokio::test]
    async fn test_update_dog_chip() -> Result<(), DbErr> {
        let dog_id = Uuid::default();
        let conn = MockDatabase::new(DatabaseBackend::Sqlite)
            .append_query_results([
                [dog::Model {
                    chip_id: "chip_1".to_string(),
                    ..Default::default()
                }],
                [dog::Model {
                    chip_id: "chip_2".to_string(),
                    ..Default::default()
                }],
            ])
            .into_connection();
        update_dog_chip(dog_id, "chip_2".to_string(), &conn).await?;
        Ok(())
    }

Partial models and Tuples

To mock query results that are not just models, but structures that implement DerivePartialModel trait, as well as tuples, we must use BTreeMap.

Let's create a partial model of the Dog, where only the dog's name and chip ID are returned.

#[derive(Debug, DerivePartialModel, PartialEq)]
#[sea_orm(entity = "dog::Entity")]
pub struct DogIdentification {
    pub name: String,
    pub chip_id: String,
}

// The function to test
pub async fn get_dog(id: Uuid, conn: &DatabaseConnection
) -> Option<DogIdentification> {
    dog::Entity::find_by_id(id)
        .into_partial_model()
        .one(conn)
        .await
        .ok()
        .flatten()
}

To mock the results of the database query, the connection should include BTreeMap with the selected fields from the partial model.

#[tokio::test]
async fn test_get_dog() -> Result<(), DbErr> {
    let dog_name = "Buddy".to_string();
    let chip_id = "chip_1".to_string();

    let conn = MockDatabase::new(DatabaseBackend::Sqlite)
        .append_query_results([[BTreeMap::from([
            ("name", Value::String(Some(dog_name.clone()))),
            ("chip_id", Value::String(Some(chip_id.clone()))),
        ])]])
        .into_connection();

    let dog_opt = get_dog(Uuid::default(), &conn).await;
    assert!(dog_opt.is_some());
    let dog = dog_opt.unwrap();
    let expected = DogIdentification {
        name: dog_name,
        chip_id,
    };
    assert_eq!(dog, expected);
    Ok(())
}

Nested partial models

If we want to get the partial model, that includes results of the left join, we need to add to the BTreeMap those fields with the table name appended as prefix. Let's modify the previous example:

#[derive(Debug, DerivePartialModel, PartialEq)]
#[sea_orm(entity = "owner::Entity")]
pub struct OwnerPartialModel { // <----- Owner's information
    pub name: String,
    pub surname: String,
}

#[derive(Debug, DerivePartialModel, PartialEq)]
#[sea_orm(entity = "dog::Entity")]
pub struct DogWithOwner {
    pub name: String,
    pub chip_id: String,
    #[sea_orm(nested)]    // <----- added nested field
    pub owner: OwnerPartialModel, 
}

// The function to test
pub async fn get_dog_with_owner(id: Uuid, conn: &DatabaseConnection
) -> Option<DogWithOwner> {
    dog::Entity::find_by_id(id)
        .left_join(owner::Entity)
        .into_partial_model()
        .one(conn)
        .await
        .ok()
        .flatten()
}


#[tokio::test]
async fn test_get_dog_with_owner() -> Result<(), DbErr> {
    let dog_name = "Buddy".to_string();
    let chip_id = "chip_1".to_string();
    let owner_name = "Jane".to_string();
    let owner_surname = "Doe".to_string();
    let conn = MockDatabase::new(DatabaseBackend::Sqlite)
        .append_query_results([[BTreeMap::from([
            ("name", Value::String(Some(dog_name.clone()))),
            ("chip_id", Value::String(Some(chip_id.clone()))),
            // Adding the owner's table name as prefix to the fields
            ("owner_name", Value::String(Some(owner_name.clone()))),
            ("owner_surname",
               Value::String(Some(owner_surname.clone()))),
        ])]])
        .into_connection();
    let dog_opt = get_dog_with_owner(Uuid::default(), &conn).await;
    assert!(dog_opt.is_some());
    let dog = dog_opt.unwrap();
    let expected = DogWithOwner {
        name: dog_name,
        chip_id,
        owner: OwnerPartialModel {
            name: owner_name,
            surname: owner_surname,
        },
    };
    assert_eq!(dog, expected);
    Ok(())
}

Delete cascade

This was, for me, the most confusing test case, because the order of models that should be appended to the query results matters! We need to pay close attention to the one-to-many relationship the Dog table has.

// Dog model
#[sea_orm::model]
#[derive(Clone, Debug, PartialEq, Eq, DeriveEntityModel, Default)]
#[sea_orm(table_name = "dog")]
pub struct Model {
    // ....fields here

    // First, the procedure table
    #[sea_orm(has_many)]
    pub procedures: HasMany<crate::procedure::Entity>,
    // Next, the visits
    #[sea_orm(has_many)]
    pub visits: HasMany<crate::visit::Entity>,
    // At lastly, vaccinations
    #[sea_orm(has_many)]
    pub vaccinations: HasMany<crate::vaccination::Entity>,
}

// Procedures model has no further relationships

// Visit's model has three more
#[sea_orm::model]
#[derive(Clone, Debug, PartialEq, Eq, DeriveEntityModel)]
#[sea_orm(table_name = "visit")]
pub struct Model {
    // ....fields here

    // First, the symptoms table
    #[sea_orm(has_many)]
    pub symptoms: HasMany<crate::symptom::Entity>,
    // And the prescription for the given visit table
    #[sea_orm(has_many)]
    pub visit_prescriptions: HasMany<crate::visit_prescription::Entity>,

// Vaccination model has no further relationships

// The function to test
pub async fn delete_dog(dog_id: Uuid, conn: &DatabaseConnection
) -> Result<(), DbErr> {
    if let Some(dog) = dog::Entity::find_by_id(dog_id).one(conn).await? {
        dog.cascade_delete(conn).await?;
    }
    Ok(())
}

Based on that definition, the order is:

Mock getting dog model
Mock getting procedure::Model -> Mock deletion
Mock getting visit::Model, symptom::Model, and visit_prescriptions::Model in three different arrays -> Mock 3 separate deletions
Mock getting vaccination::Model -> Mock deletion
Finally, mock deleting the dog model!

#[tokio::test]
async fn test_cascade_delete_dog() -> Result<(), DbErr> {
    let id = Uuid::max();
    let time = datetime!(2026-04-08 00:00:01);
    let conn = MockDatabase::new(DatabaseBackend::Sqlite)
        // First, we find the model to delete
        .append_query_results([[dog::Model {
            id,
            name: "Jack".to_string(),
            owner_id: Default::default(),
            chip_id: "chip_1".to_string(),
        }]])
        // First one-to-many relationship in the `dog` table
        // is procedure, we must get it and then delete it
        .append_query_results([[procedure::Model {
            id,
            dog_id: Uuid::default(),
            procedure_description: "test procedure".to_string(),
            datetime: time.clone(),
        }]])
        .append_exec_results([MockExecResult::default()])
        // Next relationship in the `dog` table is visits, 
        // which in turn has few one-to-many relationships
        .append_query_results([
            // first, select the visit model
            [visit::Model {
                id,
                dog_id: Uuid::default(),
                diagnosis: "test diagnosis".to_string(),
                datetime: time.clone(),
            }
                .into_mock_row()],
            // then, the first 1-to-m relationship in the `visit` table
            [symptom::Model {
                id,
                visit_id: Uuid::new_v4(),
                symptom: "Test symptom".to_string(),
            }
                .into_mock_row()],
            // then, the next 1-to-m relationship in the `visit` table
            [visit_prescription::Model {
                id,
                visit_id: Uuid::new_v4(),
                prescription_id: Default::default(),
                datetime: time.clone(),
            }
                .into_mock_row()],
        ])
        // remove all three models
        .append_exec_results([MockExecResult::default()])
        .append_exec_results([MockExecResult::default()])
        .append_exec_results([MockExecResult::default()])
        // The last relationship in the `dog` table 
        // is vaccinations, get the model and delete it
        .append_query_results([[vaccination::Model {
            id,
            dog_id: Uuid::default(),
            vaccine_sku: "vaccine_000".to_string(),
            date: date!(2026-04-08).into(),
        }]])
        .append_exec_results([MockExecResult::default()])
        // Finally, mock deleting the `dog` model
        .append_exec_results([MockExecResult::default()])
        .into_connection();
    let result = delete_dog(Uuid::default(), &conn).await;
    assert!(result.is_ok());
    Ok(())
}

You can find the code here: https://github.com/MilaKyr/sea-orm-test-examples.

What is your experience with SeaOrm and mocking database functions?
Do you prefer to use Traits and write custom mocking structures?

Cover photo by Illia Horokhovsky on Unsplash.