You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
//! In that original migration, default menu items were hard-coded and inserted
6
+
//! into the `dynamic_sidebar` table. This approach mixes schema definition
7
+
//! with data initialization, which is no longer the desired practice.
8
+
//!
9
+
//! Key principles applied in this migration:
10
+
//!
11
+
//! 1. **Schema vs. Data Separation**
12
+
//! - Migrations should only define or modify database **schema** (tables, columns, indexes).
13
+
//! - They should **not** insert default or seed data.
14
+
//! - Default menu data is now managed at **runtime** via a bootstrap method (`DynamicSidebarStorage::bootstrap_sidebar`) that reads from configuration (e.g., `sidebar.default.toml`).
15
+
//!
16
+
//! 2. **Purpose of This Migration**
17
+
//! - Remove historical default data inserted by the old migration.
18
+
//! - Keep the table structure and indexes intact, so the table is empty but ready for runtime seeding.
19
+
//! - This ensures **new environments** or **fresh deployments** do not carry legacy hard-coded menu items.
20
+
//!
21
+
//! 3. **Future Default Menu Management**
22
+
//! - Default menu items are now fully configurable and maintained via `sidebar.default.toml` or application config.
23
+
//! - `DynamicSidebarStorage::bootstrap_sidebar` is responsible for checking if the table is empty and inserting defaults at runtime.
24
+
//! - This approach provides flexibility, maintains backward compatibility, and separates schema migrations from dynamic, configurable data.
0 commit comments