{"id":19128803,"url":"https://github.com/peerlibrary/meteor-peerdb-migrations","last_synced_at":"2026-05-02T22:34:16.616Z","repository":{"id":24368814,"uuid":"27768002","full_name":"peerlibrary/meteor-peerdb-migrations","owner":"peerlibrary","description":"PeerDB migrations","archived":false,"fork":false,"pushed_at":"2021-10-26T23:58:04.000Z","size":49,"stargazers_count":3,"open_issues_count":0,"forks_count":1,"subscribers_count":5,"default_branch":"master","last_synced_at":"2025-01-03T10:45:13.972Z","etag":null,"topics":["database","meteor","meteor-package","migrations"],"latest_commit_sha":null,"homepage":null,"language":"CoffeeScript","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"bsd-3-clause","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/peerlibrary.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null}},"created_at":"2014-12-09T13:34:46.000Z","updated_at":"2021-10-26T23:58:06.000Z","dependencies_parsed_at":"2022-08-22T17:30:23.640Z","dependency_job_id":null,"html_url":"https://github.com/peerlibrary/meteor-peerdb-migrations","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/peerlibrary%2Fmeteor-peerdb-migrations","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/peerlibrary%2Fmeteor-peerdb-migrations/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/peerlibrary%2Fmeteor-peerdb-migrations/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/peerlibrary%2Fmeteor-peerdb-migrations/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/peerlibrary","download_url":"https://codeload.github.com/peerlibrary/meteor-peerdb-migrations/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":240199243,"owners_count":19763825,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["database","meteor","meteor-package","migrations"],"created_at":"2024-11-09T06:05:41.950Z","updated_at":"2026-05-02T22:34:16.577Z","avatar_url":"https://github.com/peerlibrary.png","language":"CoffeeScript","funding_links":[],"categories":[],"sub_categories":[],"readme":"PeerDB Migrations\n=================\n\nMeteor smart package which provides migrations for [PeerDB](https://github.com/peerlibrary/meteor-peerdb)\nreactive database layer.\n\nAdding this package to your [Meteor](http://www.meteor.com/) application enables migrations on all documents defined\nusing PeerDB.\n\nServer side only.\n\nInstallation\n------------\n\n```\nmeteor add peerlibrary:peerdb-migrations\n```\n\nMigrations\n----------\n\nIn any large project your documents' schemas will evolve through time. While MongoDB does not really enforce\nany schema, your program logic might require one. It is error prone to allow documents with various versions\nof schemas to exist at the same time and it makes your program code more complicated.\n\nTo address this, PeerDB migrations provide you with a way to define schema migrations. They are applied\nautomatically on a startup of your application to migrate any documents as necessary. To know which documents\nare at which schema version, PeerDB migrations add a `_schema` field to all PeerDB documents with a\n[semantic version](http://semver.org/) number. This allows recovery of partially migrated collections and\nimporting documents with a different schema version.\n\nTo define a migration, extend a class `Document.PatchMigration`, `Document.MinorMigration`, or\n`Document.MajorMigration`, depending on whether your schema change is a backwards-compatible bug fix,\nyou are adding functionality in a backwards-compatible manner, or you are making an incompatible\nchange, respectively. By default migrations just update the schema version:\n\n```coffee\nclass Migration extends Document.PatchMigration\n  name: \"Migration not really doing anything with data\"\n\n  forward: (document, collection, currentSchema, newSchema) =\u003e\n    migrated: 0\n    all: collection.update {_schema: currentSchema}, {$set: _schema: newSchema}, {multi: true}\n\n  backward: (document, collection, currentSchema, oldSchema) =\u003e\n    migrated: 0\n    all: collection.update {_schema: currentSchema}, {$set: _schema: oldSchema}, {multi: true}\n\nPost.addMigration new Migration()\n```\n\nThe base migrations class uses the migration definitions above. You have to define both `forward` and `backward`\nmethods, but you can leave them undefined to use inherited definitions. Methods should return an\nobject containing `migrated` and `all` counts. `migrated` is the count of all documents which were migrated,\nwhile `all` includes documents which were not really migrated (maybe because they were not applicable\nfor the given migration), but they still exist in the collection and only their schema version was updated.\nThe method must update the schema version on all documents in a collection. (An easy pattern is to first migrate\napplicable documents and then call `super` for the rest, returning the combined counts.)\n\nInside a migration method you should use [DirectCollection](https://github.com/peerlibrary/meteor-directcollection),\nprovided to you as a `collection` argument. If you need access to other collections in your migrations,\nyou should use `DirectCollection` as well. `DirectCollection` is a library which provides a Meteor-like API for accessing\nMongoDB, but bypasses Meteor completely, allowing you direct interaction with the database. This is necessary\nin migrations because collection names could be changing during migrations and Meteor cannot really handle that.\n\nYou should call `addMigration` in the order you want migrations to be applied. The easiest way to assure that is\nto create a directory `server/migrations/` in your project and have multiple files with `XXXX-description.coffee`\nfilenames, where `XXXX` is a consecutive number for the order you want, each file adding one migration.\n\nThere are some migration classes predefined:\n\n* `AddReferenceFieldsMigration` – you are adding fields to a reference to be synced and you want to trigger resyncing of fields\n* `RemoveReferenceFieldsMigration` – you are removing fields from a reference and you want to trigger resyncing of fields\n* `AddGeneratedFieldsMigration` – you are adding auto-generated fields and you want to trigger generation of fields - you should pass a list of field names\n* `ModifyGeneratedFieldsMigration` – you are modifying auto-generated fields and you want to trigger regeneration of fields - you should pass a list of field names\n* `RemoveGeneratedFieldsMigration` – you are removing auto-generated fields - you should pass a list of field names\n* `AddOptionalFieldsMigration` – you are adding optional fields - you should pass a list of field names\n* `AddRequiredFieldsMigration` – you are adding required fields - you should pass a map between new field names and their initial values\n* `RemoveFieldsMigration` – you are removing fields - you should pass a map between field names to be removed, and their values which should be set when reverting the migration\n* `RenameFieldsMigration` – you are renaming fields - you should pass a map between current field names and the new names\n\nTo rename a collection backing the document, use `renameCollectionMigration`:\n\n```\nPost.renameCollectionMigration 'oldPosts', 'Posts'\n```\n\nSettings\n--------\n\n### `PEERDB_MIGRATIONS_DISABLED=` ###\n\nIf you want migrations to not run, set `PEERDB_MIGRATIONS_DISABLED` to a true value. Recommended setting is that only\n*one* web-facing instance has migrations enabled and all other, including PeerDB instances, have them disabled. This\nprevents any possible conflicts which could happen because of running migrations in parallel (but you are writing all\nyour migrations in a way that conflicts will never happen, using the\n[Update If Current pattern](http://docs.mongodb.org/manual/tutorial/isolate-sequence-of-operations/#update-if-current),\naren't you?).\n\nDisabling migrations just disables running them; documents are still populated with the `_schema` field.\n\nExamples\n--------\n\nSee migrations in:\n * [PeerLibrary](https://github.com/peerlibrary/peerlibrary/tree/development/server/migrations)\n * [PeerMind](https://github.com/peer/mind/tree/master/packages/core/migrations)\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fpeerlibrary%2Fmeteor-peerdb-migrations","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fpeerlibrary%2Fmeteor-peerdb-migrations","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fpeerlibrary%2Fmeteor-peerdb-migrations/lists"}