2011-03-17 11 views
13

Para un proyecto en el que estoy trabajando actualmente, necesito implementar el control de versiones de objetos. Lamentablemente, necesito mantener un historial completo de cada objeto, por lo que una sola solución de tabla como Papertrail se volvería rápidamente inmanejable. Sin embargo, hay características de Papertrail que me gustan, que no he podido encontrar en una solución con tablas individuales para cada modelo (como act_as_versioned).Control de versiones de objetos en Rails, como Papertrail pero tablas individuales

  • Capacidad para almacenar meta-información tanto de controlador y el modelo
  • datos es serializado por lo que los cambios de esquema no modifican la tabla de versiones
  • métodos de gran alcance para las versiones que atraviesan
  • seguimiento automático de cambio de responsabilidad

también hay algunas características que no tiene Papertrail que sería bonificaciones:

  • El soporte integrado versión diff
  • diferencial en lugar de versiones completas

Estoy considerando actualmente se bifurcan Papertrail utilizar tablas individuales para cada modelo, pero me gustaría guardar ese esfuerzo si hay una solución existente .

Actualización: Vestal versiones por defecto usa una sola tabla, pero proporcionando una clase versión personalizada para cada modelo y utilizando el método "set_table_name" de ActiveRecord, yo era capaz de crear tablas separadas para cada modelo. Vestal Versions también ha incorporado compatibilidad con diff, aunque su interfaz no es tan poderosa como Papertrails. También carece de soporte de asociación.

Actualización 2: Como PaperTrail parece ser un proyecto más activo que he bifurcadas la gema y se añaden en apoyo de la clase personalizada similar a Vestal versiones que ahora permite la posibilidad de definir tablas separadas por modelo. Mi fork está aquí, pero espero que en breve se ingrese al repositorio principal del proyecto. https://github.com/benzittlau/paper_trail

+0

¿Por qué exactamente necesita una tabla por modelo? El plugin old-school acts_as_versioned funciona de esta manera. – Unixmonkey

+0

Se requiere una tabla separada para cada modelo ya que una sola tabla para todos los objetos versionados crecerá rápidamente a un tamaño no manejable, especialmente porque espero que esta tabla se lea y se escriba con frecuencia. –

Respuesta

11

Puede especificar subclases versión personalizada con la opción: class_name:

class Post < ActiveRecord::Base 
    has_paper_trail :class_name => 'PostVersion' 
end 

class PostVersion < Version 
    # custom behaviour, e.g: 
    set_table_name :post_versions 
end 

Esto le permite almacenar versiones de cada modelo en una tabla separada, lo cual es útil si usted tiene una gran cantidad de versiones está creando.

+0

¿Realmente necesitamos usar set_table_name ya que es el nombre de tabla derivado predeterminado de la clase? PostVersion => post_versions – gamov

+1

es de hecho si su clase hereda de AR :: Base, que no es el caso aquí. –

+0

¿Puedo comenzar a usar diferentes tablas una vez que ya tengo un montón de historial en la única tabla? – holaSenor

0

He estado usando Vestal Versions, una joya rieles/plugin que utiliza el patrón de recuerdo para crear una tabla de historial, y se ahorra un diff de atributos en after_save y devoluciones de llamada after_destroy.

También registra cuándo se modificó e incrementa un número de versión para que pueda retroceder a una versión determinada o una versión presente en una fecha u hora determinada.

A continuación, puedo tirar de un objeto así:

@user = User.last 
@user.versions.last.changes #=> {:name => ['Robert','Bob']} 

Soy un fan muy grande.

+0

Versiones Vestal, como Papertrail, usa una sola tabla para almacenar sus objetos versionados, por lo que no se ajusta a mi aplicación como se explica en la publicación original. –

Cuestiones relacionadas