From 30d2baa234e31aaed6bc2d8f1d6fd18dbcf2bb3a Mon Sep 17 00:00:00 2001
From: zerosnacks <95942363+zerosnacks@users.noreply.github.com>
Date: Sat, 19 Sep 2026 18:15:08 +0200
Subject: [PATCH] feat: expose bundled schema SQL

Expose Steda's generated release schema as SCHEMA_SQL so downstream
applications can apply the database schema that exactly matches the
linked crate version.

Keep schema ownership in Steda instead of requiring consumers to copy
generated SQL into their own migration trees, reducing the risk of Rust
and database versions drifting independently.

Update schema reapplication coverage to exercise the public artifact.
---
 README.md       | 2 ++
 src/lib.rs      | 6 ++++++
 tests/schema.rs | 6 +++---
 3 files changed, 11 insertions(+), 3 deletions(-)

diff --git a/README.md b/README.md
index 167a450..42cce52 100644
--- a/README.md
+++ b/README.md
@@ -56,6 +56,8 @@ Download `steda.sql` from the matching [Steda release](https://github.com/selemi
 psql "$DATABASE_URL" --single-transaction -v ON_ERROR_STOP=1 -f steda.sql
 ```
 
+Applications that own database bootstrap can instead apply [`steda::SCHEMA_SQL`](https://docs.rs/steda/latest/steda/constant.SCHEMA_SQL.html) from the linked crate release in the same atomic manner.
+
 When upgrading Steda, apply the new release's `steda.sql` the same way before starting binaries built against that release. Database upgrades remain compatible within a major release line. A future major release may introduce breaking storage changes and require an explicit migration procedure, such as draining workers or running a one-time upgrade script. Any such requirements will be documented in the release notes. Mixed-version deployments are not guaranteed unless a release explicitly states otherwise.
 
 ## Features
diff --git a/src/lib.rs b/src/lib.rs
index dbda155..82706dd 100644
--- a/src/lib.rs
+++ b/src/lib.rs
@@ -320,6 +320,12 @@ pub mod middleware {
     };
 }
 
+/// Complete re-applicable PostgreSQL schema artifact for this Steda release.
+///
+/// Applications that own database bootstrap may apply this SQL atomically before starting
+/// producers or workers. Reapply the value from the new Steda release when upgrading.
+pub const SCHEMA_SQL: &str = include_str!("../sql/steda.sql");
+
 pub use context::{TaskContext, TaskWait};
 pub use error::{Error, Result};
 pub use queue::Queue;
diff --git a/tests/schema.rs b/tests/schema.rs
index b88d4bf..5be53e1 100644
--- a/tests/schema.rs
+++ b/tests/schema.rs
@@ -7,7 +7,7 @@ mod common;
 mod tests {
     use serde_json::{Value, json};
     use sqlx::{AssertSqlSafe, PgPool};
-    use steda::{Result, RunId, Steda, Task, TaskSnapshot};
+    use steda::{Result, RunId, SCHEMA_SQL, Steda, Task, TaskSnapshot};
 
     use super::common::unique_queue;
 
@@ -15,7 +15,7 @@ mod tests {
 
     #[sqlx::test]
     async fn merged_schema_can_be_reapplied_without_losing_state(pool: PgPool) -> Result<()> {
-        sqlx::raw_sql(include_str!("../sql/steda.sql")).execute(&pool).await?;
+        sqlx::raw_sql(SCHEMA_SQL).execute(&pool).await?;
 
         let queue_name = unique_queue("schema_reapply");
         let queue = Steda::from_pool(pool.clone()).queue(queue_name.clone())?;
@@ -23,7 +23,7 @@ mod tests {
         let spawned = queue.spawn(SCHEMA_PROBE, json!({"preserved": true})).await?;
         assert_eq!(spawned.snapshot().await?, Some(TaskSnapshot::Pending));
 
-        sqlx::raw_sql(include_str!("../sql/steda.sql")).execute(&pool).await?;
+        sqlx::raw_sql(SCHEMA_SQL).execute(&pool).await?;
 
         assert_eq!(spawned.snapshot().await?, Some(TaskSnapshot::Pending));
         assert!(Steda::from_pool(pool).queues().await?.contains(&queue_name));