activerecord-virgodb-adapter 0.1.2 → 0.1.4

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 757fecfe8176d3354cf42df451f013c814c2699b3ac1206a055a3ada8196fd10
-  data.tar.gz: 945f9ab23d59f055951dcbe55786545f106d7c0c90a26c23699a9e61a32cbec2
+  metadata.gz: d6376b065e29146c096491b6ce2a68e4331e806161a570b6549b068561a85f1f
+  data.tar.gz: 1555e75fdf0c2418c1d3439fb1940f7dd284e48e28109248ffd249454b41dc55
 SHA512:
-  metadata.gz: 24f8356243e4ab3349e1b94c4fb4d561d28e86575442bca4e7185cb1c2a39c745c3f98a25b7bdca0e06f09b5f9cf50af121963fba72d021d2ab3e61b53461dc3
-  data.tar.gz: f9c6ced6922d7254082c043e2317507d303b63fb4708a957ca8cf33f6fb462711e72690a19074639f37138f5d0e80c884ec13cc0e08d4fd9255edc99ad0df026
+  metadata.gz: ab5ef2e0113e6c38295495cb10d1c2ca4bb77d135b65a636cf58aee8777146bc29795b1c7d3d2950898735a81367e2d88e3ce235a3d4f567b7e934ae8d69e885
+  data.tar.gz: 7375e48809a1b05cc4a1ae8add6ed5e1a36d33a4564e0c711a8a8228e910e4f79d9ad039aaeccd66b839b88a4ff31640aec9e5d0f9ac246398d320b6b1224611

data/lib/active_record/connection_adapters/virgodb_adapter.rb

@@ -37,9 +37,13 @@ module ActiveRecord
     #
     # Additive-only, matching `Manifest::register_schema_version`'s own
     # rule and virgodb's immutable-Parquet philosophy: `remove_column`,
-    # `rename_column`, and `change_column` are all disabled outright rather
-    # than silently letting the real SQLite table drift out of sync with
-    # what `schema_versions` describes.
+    # `rename_column`, `change_column`, and `rename_table` are all disabled
+    # outright, and `assert_additive!` (below) catches every OTHER way an
+    # existing column can be altered (`change_column_null`,
+    # `change_column_default`, `remove_columns`, and anything else that
+    # reaches `create_table` via SQLite3Adapter's rebuild-the-table
+    # fallback) -- all rather than silently letting the real SQLite table
+    # drift out of sync with what `schema_versions` describes.
 
     # virgodb's raw "Timestamp" type (crates/compact/src/schema.rs) is plain
     # UNIX seconds -- an Integer, not a real SQL DATETIME/TIMESTAMP string --
@@ -50,9 +54,8 @@ module ActiveRecord
     # real failure modes from that mismatch, not just cosmetic ones:
     #
     # 1. `Type::DateTime.new.cast("0")` -- "0" being a perfectly valid
-    #    epoch-seconds default (e.g. exit_page_at/split_test_id_at's own
-    #    DEFAULT 0 sentinel, see
-    #    db/migrate_virgodb/20260727000002_create_ahoy_visits.rb in hintpot)
+    #    epoch-seconds default (e.g. a real host app declaring `DEFAULT 0`
+    #    as a sentinel on a nullable-in-spirit timestamp column)
     #    -- returns nil. `Column#default` itself is unaffected (DateTime is
     #    `mutable?`, so `Column#initialize` keeps the raw string rather than
     #    deserializing it -- see ActiveModel::Type::DateTime#mutable?'s own
@@ -158,9 +161,9 @@ module ActiveRecord
         #    falls through to `Type.default_value`, an untyped
         #    `ActiveModel::Type::Value` whose `.type` is nil.
         # 2. An `AnyLast <type> <order_by_column>` column (the two-scalar-
-        #    column tuple-workaround pairs -- see
-        #    db/migrate_virgodb/20260727000002_create_ahoy_visits.rb in
-        #    hintpot) can get a WRONG match instead of no match: Rails'
+        #    column tuple-workaround pairs a real host app might use to
+        #    emulate ClickHouse-style last-touch columns) can get a WRONG
+        #    match instead of no match: Rails'
         #    %r(date)i is an unanchored substring regex, and
         #    "AnyLast String updated_at" contains the substring "date"
         #    (from "upDATEd_at") purely by accident, mis-casting a String
@@ -233,6 +236,70 @@ module ActiveRecord
         raise NotImplementedError, "virgodb schemas are additive-only -- an existing column's type can't change"
       end
 
+      # Not caught by `assert_additive!` -- SQLite renames a table via a
+      # native, lightweight `ALTER TABLE ... RENAME TO ...` (unlike
+      # `remove_columns`/`change_column_null`/`change_column_default`,
+      # never `alter_table`'s rebuild-the-table fallback), so it never
+      # reaches `record_schema_version!` at all. Confirmed by direct
+      # repro: renaming left `schema_versions` (and, on the real Rust
+      # side, `run_files`/`inline_batches`/every other manifest catalog
+      # table `manifest::Manifest` scopes by `table_name`) still keyed
+      # under the OLD name while the real SQLite table now answers to the
+      # new one -- every future migration or query against either name
+      # would silently miss the other's history. Blocked outright, same
+      # as the other identity-changing operations above: nothing in this
+      # codebase's fixed table set (events/visits/engagements/heatmaps,
+      # hardcoded in `Virgodb::Registry::TABLES` on the Ruby side and
+      # implicitly on the Rust side by whatever `table_name` callers pass)
+      # has a legitimate reason to rename.
+      def rename_table(table_name, new_name, **options)
+        raise NotImplementedError, "virgodb schemas are additive-only -- a table can't be renamed once created (schema_versions and the Rust-side manifest catalog are both keyed by table_name)"
+      end
+
+      # `ActiveRecord::Tasks::DatabaseTasks.truncate_tables(db_config)` --
+      # what `db:truncate_all` and, through it, `db:seed:replant` both run
+      # for every configured database -- passes `conn.tables` (literally
+      # everything `create_table` has ever touched, unfiltered) straight
+      # into this method. `AbstractAdapter::DatabaseStatements
+      # #truncate_tables` already subtracts exactly two names from that
+      # list before truncating: `pool.schema_migration.table_name` and
+      # `pool.internal_metadata.table_name` -- Rails' OWN bookkeeping
+      # tables. `schema_versions` (this adapter's bookkeeping table) and
+      # the Rust side's manifest catalog tables (`Manifest::open()`'s
+      # bootstrap, crates/manifest/src/lib.rs: run_files, inline_batches,
+      # orphaned_files, flush_completions, maintenance_lease, tombstones)
+      # get no such exemption -- Rails has no way to know this adapter's
+      # `tables` list contains anything other than real app data.
+      #
+      # Found by a real host app, not assumed: its CI ran
+      # `db:seed:replant` (truncate_all + reseed) as its last step, which
+      # silently zeroed out schema_versions with nothing to reload it
+      # afterward -- `ActiveRecord::Migration.maintain_test_schema!` only
+      # checks for PENDING migrations, saw none, and left the now-empty
+      # table alone. The NEXT `bin/rails test` run then failed immediately:
+      # nothing left to read a table's committed column list from.
+      # Confirmed directly against a real manifest: truncate_all correctly
+      # left schema_migrations/ar_internal_metadata alone but zeroed
+      # schema_versions (4 rows -> 0).
+      #
+      # Fixed the same way Rails protects its own two tables: subtract
+      # this adapter's catalog tables before delegating to `super`. All 7
+      # names are excluded on principle, even though a manifest built from
+      # pure-Ruby migrations alone only ever populates schema_versions
+      # (the other 6 only exist once the Rust side's `Manifest::open()`
+      # has bootstrapped them) -- truncating any of them out from under a
+      # running maintenance thread (crates/compact/src/maintenance.rs)
+      # would be exactly as destructive as this bug, just harder to
+      # trigger from Ruby alone.
+      MANIFEST_CATALOG_TABLES = %w[
+        schema_versions run_files inline_batches orphaned_files
+        flush_completions maintenance_lease tombstones
+      ].freeze
+
+      def truncate_tables(*table_names)
+        super(*(table_names - MANIFEST_CATALOG_TABLES))
+      end
+
       private
 
       # Reads the table back via ActiveRecord's own column introspection --
@@ -274,9 +341,61 @@ module ActiveRecord
           { "name" => c.name, "virgodb_type" => c.sql_type, "nullable" => c.null, "default" => stringify_default(c.default) }
         end
 
+        assert_additive!(table_name, cols)
         insert_schema_version!(table_name, cols)
       end
 
+      # `remove_column`/`rename_column`/`change_column` are blocked outright
+      # above, but SQLite3Adapter has THREE other public methods
+      # (`change_column_null`, `change_column_default`, `remove_columns`
+      # -- plural) that were never individually overridden and reach the
+      # exact same place: none of them support SQLite's native ALTER
+      # TABLE, so `SQLite3Adapter#alter_table` falls back to its
+      # rebuild-the-table strategy (`move_table`/`copy_table`), which
+      # calls `create_table` -- THIS adapter's overridden one -- as part
+      # of that rebuild. Confirmed empirically, not assumed: calling
+      # `change_column_null` on a real virgodb-backed table raised
+      # nothing at all, silently succeeded, and left `schema_versions`
+      # with a brand-new "version" whose columns had both the intended
+      # change AND every untouched column's `virgodb_type` corrupted to
+      # Rails' generic SQL type name ("INTEGER" instead of "Int64") --
+      # the exact same re-introspection landmine `record_added_column!`'s
+      # own doc comment already documents and specifically avoids for
+      # `add_column`. Without this check, that corrupted row would reach
+      # the Rust side's `manifest::register_schema_version`, either
+      # getting rejected there too (in which case the Ruby-side SQLite
+      # table and the Rust-side manifest catalog would have already
+      # silently diverged -- the migration "succeeded" from Rails'
+      # perspective) or, worse, if a future version happened to look
+      # additive by coincidence, corrupting every future read of that
+      # column's stored type.
+      #
+      # Rather than hunt down and individually block every current and
+      # future Rails method that can reach `alter_table`'s rebuild path,
+      # this enforces the actual invariant (mirroring `manifest::Manifest
+      # ::register_schema_version`'s own `columns.starts_with(&current)`
+      # check exactly) at the one place ALL of them funnel through:
+      # `record_schema_version!`, called by the overridden `create_table`
+      # on every real table AND on every rebuild `create_table` call
+      # `alter_table` makes internally. A genuinely new table (no prior
+      # schema_versions row) always passes trivially. Runs inside the
+      # same transaction `alter_table` already wraps its rebuild in, so
+      # raising here rolls back the real SQLite table change too --
+      # verified directly: after a rejected `change_column_null` call,
+      # the table's real column list is byte-for-byte what it was before
+      # the call, not left half-rebuilt.
+      def assert_additive!(table_name, new_cols)
+        current_json = select_value("SELECT columns FROM schema_versions WHERE table_name = #{quote(table_name)} ORDER BY version DESC LIMIT 1")
+        return unless current_json
+
+        current_cols = JSON.parse(current_json)
+        return if new_cols.first(current_cols.length) == current_cols
+
+        raise NotImplementedError,
+          "virgodb schemas are additive-only -- table `#{table_name}`'s existing columns can't be removed, reordered, renamed, or have their type/nullable/default changed (only add_column is supported for evolving an existing table). " \
+          "current columns: #{current_cols.inspect}; attempted: #{new_cols.inspect}"
+      end
+
       # A migration's `default:` (e.g. `t.column :clid, "String", null:
       # false, default: ""`) round-trips through `columns(table_name).first
       # .default` as a real, correctly-typed Ruby value now (String/Integer/

data/lib/active_record/tasks/virgodb_database_tasks.rb

@@ -113,6 +113,14 @@ module ActiveRecord
         raw = SQLite3::Database.new(path, readonly: true)
         raw.busy_timeout = 5_000
         raw.execute("SELECT DISTINCT table_name FROM schema_versions").flatten
+      rescue SQLite3::SQLException
+        # File.exist? isn't proof schema_versions exists -- SQLite
+        # auto-creates an empty file the instant something connects to a
+        # path that doesn't exist yet, and Rails' parallel-test setup
+        # (ActiveRecord::TestDatabases.create_and_load_schema, one file per
+        # worker) does exactly that via schema_up_to_date? moments before
+        # calling drop. Nothing to clean up in that case.
+        []
       ensure
         raw&.close
       end

metadata

@@ -1,7 +1,7 @@
 --- !ruby/object:Gem::Specification
 name: activerecord-virgodb-adapter
 version: !ruby/object:Gem::Version
-  version: 0.1.2
+  version: 0.1.4
 platform: ruby
 authors:
 - virgodb