db_meta 0.14.1 → 0.14.3

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 613dba8df67586f3a98b0282ea2eba0acee08368b7842c3740624a03700b6feb
-  data.tar.gz: 2c727117d8873dd58a7753eb1e80032082dd4c3da3cc744b597091c3cb18af3a
+  metadata.gz: 6985559c2b69ce1a73d675fa71bcd711eca07a8ee76186f78facad27f71e13ca
+  data.tar.gz: 7b52884f4681245472a28ecc743fa827382e4c5c71f563912865e81cfbcd36f8
 SHA512:
-  metadata.gz: e4c8637ed18a53a34be8fc9b0ba2b06460301f0883f757f4f9b9f409936338f0e230e46a8c8cc7cd3e0665d2c8551f703a13957676eadb1c64095f6e9e8b84a4
-  data.tar.gz: 91f156e1f312922e81ad795fd56a906a548bb3da5d3737a2cd394a68118a0cf3e6655e61b0bb0d175861db34a9b47ec074a443cd4adeb5322dbf7a503e3eae52
+  metadata.gz: e2aab5003edce86c9e71bd554ec73ec492ebfd24dbcb5bcb00df174c8e41192a80a75241dbd19fe1dd2bd7b12683ff9cc8e7f7d0c70e3f7afa6999b0473ef2ef
+  data.tar.gz: a59f1ab519d3438018ec68e9e54b5da5063301545d9f258aa2f734fecef9d7e73230588a0efe17e83e292d45a8965e92baf9abb66ba40c94b4457b4faf989932

data/CHANGELOG.md

@@ -1,3 +1,13 @@
+## [0.14.3] - 2026-04-28
+
+### Changed
+- Materialized view extracts now reuse the `INTERVAL` expression as the `START WITH` clause (e.g. `START WITH TRUNC(SYSDATE+1) NEXT TRUNC(SYSDATE+1)`) instead of emitting `START WITH SYSDATE`. Using `SYSDATE` caused the first refresh to fire at script-execution time, breaking cadence-aligned schedules (a midnight-daily MV would refresh at install time, not midnight, until the next cycle). Reusing the interval makes the first refresh align with the schedule regardless of when the script runs. `preserve_mview_schedule: true` still keeps the live `TO_DATE(...)` form.
+
+## [0.14.2] - 2026-04-28
+
+### Changed
+- Materialized views with a refresh interval are extracted as `START WITH SYSDATE NEXT <interval>` by default, instead of using the live `USER_REFRESH.NEXT_DATE`. The next_date advances on every refresh cycle and made schema diffs noisy across instances. Pass `preserve_mview_schedule: true` to `extract` to keep the original `TO_DATE(...)` form when the exact next-refresh moment matters.
+
 ## [0.14.1] - 2026-04-28
 
 ### Changed

data/README.md

@@ -39,6 +39,9 @@ A few decisions worth knowing about, especially if you compare extracts across i
 
 - **Auto-generated `SYS_*` constraint names are stripped from the output.** Oracle invents names like `SYS_C0012345` for unnamed constraints, and those names differ between instances — making schema diffs noisy. Constraints with a `SYS_*` name are emitted without an explicit `CONSTRAINT <name>` clause; on import, Oracle just generates a fresh name. User-given constraint names are preserved as-is.
 - **Redundant `NOT NULL` CHECK constraints are omitted.** Oracle exposes column-level `NOT NULL` both as a column attribute and as a `SYS_*` CHECK constraint with a body of `"COL" IS NOT NULL`. The column-level form is already in the table DDL, so the duplicate CHECK is filtered out.
+- **Materialized views reuse the `INTERVAL` expression as the schedule start.** Oracle's `USER_REFRESH.NEXT_DATE` advances on every refresh cycle, so emitting it would make the DDL diverge between instances. The default output therefore writes `START WITH <interval> NEXT <interval>` — e.g. `START WITH TRUNC(SYSDATE+1) NEXT TRUNC(SYSDATE+1)`. This keeps the first refresh aligned with the schedule cadence (a midnight-daily MV will first refresh at the next midnight, regardless of when the script runs), where `START WITH SYSDATE` would have triggered an off-cadence refresh at install time. Note that Oracle does not preserve the *originally specified* start date in its data dictionary — once an MV has refreshed at least once, the original is gone — so there's no way to round-trip an explicit user-given start. Pass `preserve_mview_schedule: true` to `extract` to keep the live `TO_DATE(...)` form when the exact next-refresh moment matters.
+
+  Tip for source DDL: where time-of-day matters (e.g. "00:05 daily"), anchor the `INTERVAL` expression — `TRUNC(SYSDATE+1) + 5/1440` rather than `SYSDATE + 1`. Anchored expressions encode the time-of-day in the formula itself, so extracts round-trip cleanly; self-referential expressions like `SYSDATE + 1` don't carry that intent and Oracle has no record of when "tomorrow at 00:05" was originally meant.
 - **Sequences start from their `MINVALUE`, not from the live `LAST_NUMBER`.** Oracle's `LAST_NUMBER` advances every time someone calls `NEXTVAL`, so emitting it would make extracts diverge between any two instances of the same schema. The default output therefore starts each sequence at its baseline (typically 1), so a fresh schema build is reproducible and diffs stay clean. If you're seeding a new schema alongside imported data and need sequences to continue past existing PK values, pass `preserve_sequence_position: true` to `extract`:
 
   ```ruby

data/lib/db_meta/oracle/types/materialized_view.rb

@@ -40,7 +40,14 @@ module DbMeta
         buffer << "CREATE MATERIALIZED VIEW #{@name}(#{@columns.map { |c| c.name }.join(", ")})"
         buffer << "BUILD #{@build_mode}"
         buffer << "REFRESH #{@refresh_method} ON #{@refresh_mode}"
-        buffer << "START WITH TO_DATE('#{@next_date}') NEXT #{@interval}" if @interval
+        if @interval
+          # Reusing @interval as the start expression means the first refresh
+          # aligns with the schedule cadence (e.g. an MV that refreshes at
+          # midnight daily will first refresh at the next midnight, regardless
+          # of when this script runs).
+          start_clause = args[:preserve_mview_schedule] ? "TO_DATE('#{@next_date}')" : @interval
+          buffer << "START WITH #{start_clause} NEXT #{@interval}"
+        end
         buffer << "#{@rewrite_enabled} QUERY REWRITE"
         buffer << "AS"
         buffer << @query

data/lib/db_meta/version.rb

@@ -1,3 +1,3 @@
 module DbMeta
-  VERSION = "0.14.1"
+  VERSION = "0.14.3"
 end

metadata

@@ -1,7 +1,7 @@
 --- !ruby/object:Gem::Specification
 name: db_meta
 version: !ruby/object:Gem::Version
-  version: 0.14.1
+  version: 0.14.3
 platform: ruby
 authors:
 - Thomi