Skip to content

Carry the rename into the data layer - #225

Merged
isc merged 7 commits into
mainfrom
rename-data-layer
Aug 5, 2026
Merged

Carry the rename into the data layer#225
isc merged 7 commits into
mainfrom
rename-data-layer

Conversation

@isc

@isc isc commented Aug 4, 2026

Copy link
Copy Markdown
Owner

Stacked on #224base branch is rename-to-arabesque, so review that one first.

#224 deliberately stopped at the surface, leaving the data under the old name.
This finishes the job without asking anyone to re-import a backup.

What moves

  • IndexedDBpiano-trainerarabesque. openDatabase() copies the old
    database's stores into the new one on first open, then deletes it.
  • localStorage — the pt- and pt: prefixes (two separators, for no
    reason) collapse into a single arabesque:. legacyKeys.js renames the keys
    in place, including the per-score strictBpm:<url> ones.

Three details worth a look

  • The legacy database is probed with indexedDB.databases(), not open():
    open() would create the very database it is testing for, making every future
    first-time visitor pay for a database they never had.
  • The copy only runs into a database we just created (oldVersion === 0), so if
    a browser somehow has data under both names, the new one wins.
  • legacyKeys.js runs as an import side effect, imported first by
    i18n.js, because i18n.js reads the stored language while its module body
    evaluates. Anything called from a page's entry script would arrive after that
    read and lose the language on the first load. For the same reason the landing
    page's inline redirect script — which runs before any module — reads both the
    new and the old key.

Test fix

test_helper.rb gains wait_for_store. The seeding tests opened the database
from Ruby after a fixed sleep, assuming the page had already created it. That
assumption was always fragile and the extra await here broke it: opening the
database first creates an empty one at the same version, which then never
upgrades, so the stores are missing for good and the library renders nothing.
They now wait on that condition rather than on the clock.

Verification

  • Vitest: 97 passed.
  • rake test: 66 runs, 1 failure — test_playback_starts_and_stops, which
    waits on piano samples fetched from a CDN. It is pre-existing and
    order-dependent
    : the parent branch fails the same test identically when run
    with the same seed (46255), and it passes in isolation on both. Worth fixing
    separately.

🤖 Generated with Claude Code

isc and others added 6 commits August 4, 2026 17:56
Renames the product everywhere it is user-visible, following the decision
recorded in NAMING.md (#222): page titles and the landing page, both locale
files, the favicon label, the exported backup filename, and the READMEs.

On the iOS side the target, directory and generated project become Arabesque,
the display name and the Bluetooth/local-network usage strings follow, and the
bundle ID moves to com.arabesque.Arabesque — the identifier has to be right
before the first App Store Connect submission, since it cannot be changed
afterwards. The CoreMIDI client and port names, which other apps can see, are
renamed too. The CI workflow and .gitignore follow the new target name.

Deliberately left alone:

- DB_NAME = 'piano-trainer' in storage.js. It is the IndexedDB database holding
  every user's fingerings, sessions and practice aggregates; renaming it would
  orphan their data. The tests that open the database by name are unchanged for
  the same reason.
- The localStorage keys (pt-*).
- The repository name and the GitHub Pages URL, so PTWebAppURL still points at
  the live deployment.
- The historical changelog entries that mention the old name: they are a dated
  record of what shipped. A new entry announces the rename instead, and says
  explicitly that practice data is untouched.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Renames the IndexedDB database from 'piano-trainer' to 'arabesque' and the
localStorage keys from the 'pt-' / 'pt:' prefixes to a single 'arabesque:' one,
rather than leaving the old name behind everywhere the data lives.

Nothing is lost in the process:

- storage.js moves the old database's contents into the new one on first open,
  then drops it. It probes with indexedDB.databases() rather than open(), since
  open() would create the very database it is testing for and make every future
  first-time visitor pay for it. The copy only happens into a database we just
  created, so existing data under the new name always wins.
- legacyKeys.js renames the localStorage keys in place. It runs as an import
  side effect, imported first by i18n.js, because i18n.js reads the stored
  language while its module body evaluates — anything invoked from a page entry
  script would arrive after that read and drop the setting.
- The landing page's inline redirect script reads both the new and the old key:
  it runs before any module, so on a returning visitor's first post-rename
  landing it would otherwise beat the migration and show them the pitch again.

Also adds test_helper's wait_for_store. The seeding tests opened the database
from Ruby after a fixed sleep, assuming the page had already created it — and
opening it first creates an empty database at the same version that then never
upgrades, so the stores are missing for good and the page renders nothing. They
now wait on that condition instead of on the clock.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
NAMING.md landed on main with the rename still listed as pending; this branch
is what does it.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
NAMING.md warned against touching DB_NAME and the localStorage keys, because a
bare rename orphans everyone's practice data. This branch does rename them, but
behind a migration, so the warning as written is now misleading.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Base automatically changed from rename-to-arabesque to main August 5, 2026 09:40
@isc
isc merged commit b1e717d into main Aug 5, 2026
2 checks passed
@isc
isc deleted the rename-data-layer branch August 5, 2026 09:45
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant