MongoMapper et migrations

Je construis une application Rails en utilisant MongoDB comme back-end et MongoMapper comme outil ORM. Supposons que dans la version 1, Je définisse le modèle suivant:

class SomeModel
  include MongoMapper::Document
  key :some_key, String
end

Plus tard dans la version 2, je me rends compte que j'ai besoin d'une nouvelle clé requise sur le modèle. Donc, dans la version 2, SomeModel ressemble maintenant à ceci:

class SomeModel
  include MongoMapper::Document
  key :some_key, String
  key :some_new_key, String, :required => true
end

Comment migrer toutes mes données existantes pour inclure some_new_key? Supposons que je sache définir une valeur par défaut raisonnable pour tous les documents existants. En de plus, supposons que dans la version 3, je me rends compte que je n'ai vraiment pas besoin de some_key du tout. Donc, maintenant le modèle ressemble à ceci

class SomeModel
  include MongoMapper::Document
  key :some_new_key, String, :required => true
end

Mais tous les enregistrements existants dans ma base de données ont des valeurs définies pour some_key, et cela ne fait que gaspiller de l'espace à ce stade. Comment puis-je récupérer l'espace?

Avec ActiveRecord, je viens de créer des migrations pour ajouter les valeurs initiales de some_new_key (dans la migration version1 -> version2) et pour supprimer les valeurs de some_key (dans la version2 -> version3 la migration).

Quelle est la façon appropriée de le faire avec MongoDB / MongoMapper? Il me semble qu'une méthode de suivi des migrations qui ont été exécutées est toujours nécessaire. Est-ce une telle chose existe?

EDITED: je pense que les gens manquent le point de ma question. Il y a des moments où vous voulez être en mesure d'exécuter un script sur une base de données pour modifier ou restructurer les données qu'il contient. J'ai donné deux exemples ci-dessus, l'un où une nouvelle clé requise a été ajoutée et l'autre où une clé peut être enlevé et l'espace peut être récupéré. Comment gérez-vous l'exécution de ces scripts? Les migrations ActiveRecord vous offrent un moyen facile d'exécuter ces scripts et de déterminer quels scripts ont déjà été exécutés et quels scripts n'ont pas été exécutés. Je peux évidemment écrire un script Mongo qui fait n'importe quelle mise à jour sur la base de données, mais ce que je cherche est un framework comme migrations qui me permet de suivre quels scripts de mise à niveau ont déjà été exécutés.

23
demandé sur Clint Miller 2009-11-20 01:52:16

9 réponses

Découvrez Mongrations... Je viens de finir de lire à ce sujet et il ressemble à ce que vous recherchez.

Http://terrbear.org/?p=249

Http://github.com/terrbear/mongrations

Cheers! Kapslok

13
répondu Jurgen 2012-06-28 16:32:52

Une option consiste à utiliser l'opération update pour mettre à jour toutes vos données à la fois. Multi update est nouveau dans les versions de développement, vous devrez donc en utiliser une.

1
répondu mdirolf 2009-11-20 19:26:10

Vous pouvez essayer cet engin que je viens de faire, mais il ne fonctionne qu'avec mongoid et rails 3 (beta 3) pour le moment. http://github.com/adacosta/mongoid_rails_migrations . Il sera mis à niveau vers rails 3 quand il sera final.

1
répondu alan 2010-05-13 15:19:54

Aussi une autre gemme pour les migrations MongoMapper https://github.com/alexeypetrushin/mongo_mapper_ext

1
répondu Alexey Petrushin 2011-05-18 22:56:38

Mongrations est un super vieux bijou, complètement obsolète. Je recommande de ne pas l'utiliser.

Exodus est un framework de migration vraiment cool pour Mongo, qui pourrait être ce que vous voulez:

Https://github.com/ThomasAlxDmy/Exodus

1
répondu user2989085 2013-11-13 18:38:29

Nous venons de construire celui-ci: https://github.com/eberhara/mongration - c'est une node module (vous pouvez le trouver sur ngp).

Nous avions besoin d'un bon cadre de migration mongodb, mais nous n'en avons pas trouvé - nous en avons donc construit un.

Il a beaucoup de meilleures fonctionnalités que les frameworks de migration régulière:

  • somme de contrôle (émet une erreur lorsqu'une migration exécutée précédemment ne correspond pas à son ancienne version)
  • persiste l'état de migration vers mongo (il n'y a pas d'état régulier fichier)
  • Prise en charge complète des jeux de répliques
  • rollbacks automatiques de poignée (les développeurs doivent spécifier les procédures de rollback)
  • possibilité d'exécuter plusieurs migrations (sync ou async) en même temps
  • possibilité d'exécuter des migrations sur différentes bases de données en même temps

J'espère que ça aide!

1
répondu Andre Eberhardt 2015-12-14 16:46:36

Clint,

Vous pouvez écrire du code pour faire des mises à jour-bien qu'il semble que la mise à jour d'un enregistrement basé sur ses propres champs ne soit pas prise en charge.

Dans un tel cas, j'ai fait ce qui suit et l'ai couru contre le serveur:

------------------------------
records = Patient.all()

records.each do |p|
  encounters = p.encounters
  if encounters.nil? || encounters.empty?
    mra = p.updated_at
    #puts "\tpatient...#{mra}"
  else
    mra = encounters.last.created_at
    #puts "\tencounter...#{mra}"
  end
  old = p.most_recent_activity
  p.most_recent_activity = mra
  p.save!
  puts "#{p.last_name} mra: #{old} now: #{mra}"
end
------------------------------
0
répondu Jon Kern 2010-07-28 17:37:41

Je parie que vous pourriez vous connecter à Activerecord:: Miration pour automatiser et suivre vos scripts "migration".

-1
répondu ToreyHeinz 2010-02-12 17:11:59

MongoDB est une base de données sans schéma. C'est pourquoi il n'y a pas de migrations. Dans la base de données elle-même, peu importe si les objets ont la clé :some_key ou la clé :some_other_key à tout moment.

MongoMapper essaie d'appliquer certaines restrictions à ce sujet, mais comme la base de données est si flexible, vous devrez maintenir ces restrictions vous-même. Si vous avez besoin d'une clé sur chaque objet, assurez-vous d'exécuter un script pour mettre à jour ces clés sur des objets préexistants ou objet qui n'a pas cette clé lorsque vous les rencontrez.

Je suis assez nouveau pour MongoDB moi-même, mais pour autant que je puisse voir, en raison de la flexibilité de la base de données sans schéma, c'est ainsi que vous devrez le gérer.

-5
répondu philnash 2009-11-20 18:09:00