metka 3.0.0 → 3.0.1

data/docs/superpowers/specs/2026-08-18-cloud-table-naming-design.md

@@ -1,105 +0,0 @@
-# Table-Strategy Summary Table Naming: `<source_table>_<columns>_cloud`
-
-**Date:** 2026-08-18
-**Status:** Approved by user
-**Target:** 3.0 release
-
-## Problem
-
-The table strategy generator derives its summary table name as
-`tagged_<source_table>` (e.g. `tagged_songs`), or
-`tagged_with_<columns>_<source_table>` when non-default source columns are
-given (e.g. `tagged_with_tags_and_genres_posts`). The prefix style reads
-poorly, sorts the table away from its source table in the schema, and is
-inconsistent with the index strategy, which names its tables
-`<source_table>_<column>_index` (e.g. `posts_tags_index`).
-
-The summary table is not a taggings join table: it holds one row per tag
-(`tag_name varchar PRIMARY KEY, taggings_count bigint`) — a tag-cloud
-aggregate maintained by triggers. The name should describe that.
-
-## Decision
-
-Rename the derived default to `<source_table>_<columns>_cloud`, with columns
-joined by `_and_`, uniformly — no special case for the default `tags` column:
-
-| Input | Old derived name | New derived name |
-|---|---|---|
-| `--source-table-name=songs` | `tagged_songs` | `songs_tags_cloud` |
-| `--source-table-name=posts --source-columns=tags genres` | `tagged_with_tags_and_genres_posts` | `posts_tags_and_genres_cloud` |
-
-This mirrors the index strategy's `<source_table>_<column>_index` pattern, so
-the two strategies' tables read as siblings in the schema
-(`songs_tags_cloud`, `songs_tags_index`), and matches the feature's name
-throughout the README and API (`tag_cloud`).
-
-Alternatives considered and rejected:
-
-- `song_taggings` (`<singular>_taggings`): Rails-idiomatic, but in the Rails
-  ecosystem "taggings" implies a join table with one row per tagging;
-  this table holds per-tag counts, so the name misleads schema readers.
-- `song_tag_counts`: semantically precise but breaks symmetry with the index
-  strategy and derives awkwardly for non-default columns.
-
-## Changes
-
-### Generator (the only code change)
-
-`lib/generators/metka/strategies/table/table_generator.rb` — `table_name`
-becomes:
-
-```ruby
-def table_name
-  return options[:table_name] if options[:table_name]
-
-  "#{source_table_name}_#{source_columns_names}_cloud"
-end
-```
-
-- The migration name keeps its existing `create_#{table_name}_table`
-  derivation (→ `create_songs_tags_cloud_table`).
-- The `--table-name` option remains as the override, unchanged.
-
-### Templates: no changes
-
-Both `migration.rb.erb` (PostgreSQL) and `migration.sqlite.rb.erb` (SQLite)
-interpolate `<%= table_name %>` throughout — trigger function names become
-`metka_ins_songs_tags_cloud()` etc. automatically. Trigger names derive from
-the source table and columns, not the summary table, so they are untouched.
-
-### Docs and fixtures (model the new convention)
-
-- `test/generators/strategies/table_generator_test.rb`: expected table and
-  migration names, including the trigger-function name assertions
-  (`metka_ins_tagged_notes` → `metka_ins_notes_tags_cloud`); trigger-name
-  assertions (`metka_ins_on_notes_...`) stay as they are.
-- `README.md` table-strategy section: `tagged_notes` → `notes_tags_cloud`,
-  `TaggedNote` → `NotesTagsCloud`, and the derived-name explanation.
-- Dummy app: `test/dummy/db/migrate/11_create_tagged_table_posts_table.rb`
-  and the `TaggedTablePost` model/test rename to the new convention
-  (summary table `table_posts_tags_cloud`).
-- `benchmark/benchmark.rb`: table strategy table (`tagged_metka_table_posts`)
-  renamed to match. `benchmark/README.md` never names the table literally, so
-  it needs no change.
-
-Pluralization note: Rails infers `notes_tags_clouds` (plural) from a model
-named `NotesTagsCloud`, so the renamed dummy model and the README example
-model must set `self.table_name = "notes_tags_cloud"` explicitly — the old
-`TaggedNote` → `tagged_notes` inference worked by accident of the naming.
-
-## Compatibility
-
-Generation-time only. The table name is baked into a migration when the user
-runs the generator; no runtime code derives or reads the `tagged_` prefix.
-Existing installs keep their `tagged_*` tables and working triggers untouched;
-only newly generated migrations change. No deprecation shim is needed. The
-README is the only doc surface (no CHANGELOG file in the repo).
-
-## Testing
-
-- Updated generator tests assert the new derived names for the default and
-  multi-column cases, and that `--table-name` still overrides.
-- Existing dummy-app trigger tests run against the renamed summary table,
-  proving the templates work unchanged with the new name.
-
-No new test types are needed.

data/forspell.dict

@@ -1,9 +0,0 @@
-# Format: one word per line. Empty lines and #-comments are supported too.
-# If you want to add word with its forms, you can write 'word: example' (without quotes) on the line,
-# where 'example' is existing word with the same possible forms (endings) as your word.
-# Example: deduplicate: duplicate
-Metka
-taggings
-benchmarked
-gutentag
-backfill: fill

data/gemfiles/rails71.gemfile

@@ -1,6 +0,0 @@
-source "https://rubygems.org"
-
-gem 'rails', '~> 7.1.0'
-gem 'activerecord', '~> 7.1.0'
-
-gemspec path: '..'

data/gemfiles/rails72.gemfile

@@ -1,6 +0,0 @@
-source "https://rubygems.org"
-
-gem 'rails', '~> 7.2.0'
-gem 'activerecord', '~> 7.2.0'
-
-gemspec path: '..'

data/gemfiles/rails80.gemfile

@@ -1,6 +0,0 @@
-source "https://rubygems.org"
-
-gem 'rails', '~> 8.0.0'
-gem 'activerecord', '~> 8.0.0'
-
-gemspec path: '..'

data/gemfiles/rails81.gemfile

@@ -1,6 +0,0 @@
-source "https://rubygems.org"
-
-gem 'rails', '~> 8.1.0'
-gem 'activerecord', '~> 8.1.0'
-
-gemspec path: '..'

data/gemfiles/railsmain.gemfile

@@ -1,5 +0,0 @@
-source "https://rubygems.org"
-
-gem 'rails', github: 'rails/rails', branch: 'main'
-
-gemspec path: '..'

data/gemfiles/rubocop.gemfile

@@ -1,4 +0,0 @@
-source "https://rubygems.org" do
-  gem "rubocop-md", "~> 1.0"
-  gem "rubocop-rails-omakase", "~> 1.1"
-end

data/metka.gemspec

@@ -1,46 +0,0 @@
-# frozen_string_literal: true
-
-lib = File.expand_path('../lib', __FILE__)
-$LOAD_PATH.unshift(lib) unless $LOAD_PATH.include?(lib)
-require 'metka/version'
-
-Gem::Specification.new do |spec|
-  spec.name = 'metka'
-  spec.version = Metka::VERSION
-  spec.authors = [ 'Igor Alexandrov', 'Andrey Morozov' ]
-  spec.email = [ 'igor.alexandrov@gmail.com', 'andrey.morozov@jetrockets.ru' ]
-
-  spec.summary = 'Rails tagging system based on PostgreSQL arrays'
-  spec.description = 'Rails tagging system based on PostgreSQL arrays'
-  spec.homepage = 'https://github.com/metka-ruby/metka'
-  spec.license = 'MIT'
-
-  spec.metadata = {
-    'homepage_uri' => spec.homepage,
-    'source_code_uri' => spec.homepage,
-    'bug_tracker_uri' => "#{spec.homepage}/issues",
-    'rubygems_mfa_required' => 'true'
-  }
-
-  # Specify which files should be added to the gem when it is released.
-  # The `git ls-files -z` loads the files in the RubyGem that have been added into git.
-  spec.files =
-    Dir.chdir(File.expand_path('..', __FILE__)) do
-      `git ls-files -z`.split("\x0").reject { |f| f.match(%r{^(test|spec|features)/}) }
-    end
-  spec.bindir = 'exe'
-  spec.executables = spec.files.grep(%r{^exe/}) { |f| File.basename(f) }
-  spec.require_paths = [ 'lib' ]
-
-  # `setting :name, default: value` is only supported since 0.13
-  spec.add_dependency 'rails', '>= 7.1'
-
-  spec.add_development_dependency 'pry', '>= 0.12.2'
-  spec.add_development_dependency 'bundler', '>= 1.3'
-  spec.add_development_dependency 'minitest', '>= 5.15'
-  spec.add_development_dependency 'pg', '>= 1.1'
-  spec.add_development_dependency 'sqlite3', '>= 2.1'
-  spec.add_development_dependency 'rake', '>= 0.8.7'
-  spec.add_development_dependency 'rubocop-rails-omakase', '>= 1.1'
-  spec.required_ruby_version = '>= 3.2'
-end