¿Qué patrón de diseño de versiones recomendaría?

Question

Tengo un requisito para crear 'versiones' en una aplicación y me preguntaba cuál es la mejor manera de abordarlo.

que tienen este patrón general:

Modelo A tiene de muchos B

Cuando en la actualización de los atributos de una necesidad de ser versionados y (B) también necesitan ser versionado sus objetos asociados. Entonces la aplicación mostrará la versión actual de A, pero también debe ser posible ver las versiones anteriores de A y sus objetos asociados.

Me gustaría utilizar una tienda de documentos, sin embargo, esto es solo una parte de la aplicación y tener una tienda de documentos y una base de datos de relaciones introduciría más complejidad.

He considerado el uso de un esquema de estrella, pero antes de progresar me preguntaba si hay un patrón de diseño flotando para resolver este problema.

Esta pregunta se inclina hacia resolver el problema de almacenar las versiones de un objeto asociado en una base de datos relacional. Donde existe una necesidad inherente de poder consultar los datos de manera efectiva (es decir, la serialización del objeto no será suficiente).

Actualización: lo que estaba pensando/han implementado, pero quieren ver si el es "una mejor manera"

,---------. 1  * ,--------. 
| Model A |----------| Model B| 
`---------'   `--------' 
|PK  |   | a_id | 
|b_version|   |version | 
|version |   `--------' 
`---------' 

Donde quisiera estar duplicando el modelo A y todos los de B y asociado incrementando el atributo de versión. Luego, haga una selección para unirse a las B a través de b_version y b.version. Me pregunto si esto se puede hacer mejor.

Answer 1

No creo que no haya un patrón de diseño de GoF específico per se para el control de versiones porque existen muchas implementaciones de él.

La implementación más simple de control de versiones es una lista vinculada de objetos. Donde cada nodo en la lista es una nueva revisión de lo que sea que sea el objeto versionable. Para ahorrar espacio, también implementa un tipo de diff que muestra la diferencia entre las revisiones. De esta forma puede almacenar diffs en la base de datos, pero también la versión final del objeto versionable, ya que el sistema de control de versiones debería poder derivar las versiones intermedias.

El esquema de base principalmente podría ser algo como esto (se puede ver este patrón en la mayoría de los sistemas wiki):

+--------------------+ 1  * +-----------------------------+ 
| VersionableObject |---------| Diff      | 
+--------------------+   +-----------------------------+ 
| lastStateContent |   | difference     | 
| originalAuthor  |   | revision     | 
| #dates and whatnot |   | # userId, dates and whatnot |  
+--------------------+   +-----------------------------+ 

Si quieres ir hardcore con la ramificación y la materia que usted podría considerar echar un vistazo en DAG, que es lo que usan los sistemas modernos de control de versiones distribuidas.

Ahora, si hablamos de su ejemplo, hay una gran cantidad de objetos que deben guardarse en configuraciones. Es decir. tenemos que elegir las revisiones de los objetos que queremos para el modelo. Significa que tenemos una relación de muchos a muchos (que se soluciona con una mesa de intermediario), algo así como esto:

+---+ 1 * +---------------+ 1 * +-----------------+ * 1 +-------+ 
| B |-------| Diff   |-------| ModelSelection |-------| Model | 
+---+  +---------------+  +-----------------+  +-------+ 
      | revisionNo |  | {PK} configId | 
      | {FK} configId |  | {FK} modelId | 
      +---------------+  +-----------------+ 

espero que esto ayude.

Answer 2

Una combinación del Memento pattern con el Observer pattern se ajusta a sus necesidades. También eche un vistazo a Visitor pattern para una posible aplicación en su caso ...

Answer 3

He resuelto este problema utilizando el plugin acts_as_versioned. Cuando lo aplica a un modelo, asume que hay un model_name_version además de la tabla model_name. Cada vez que se guarda un modelo, la versión anterior junto con una marca de tiempo se copia en la tabla model_name_version.

Este enfoque mantiene el tamaño de la tabla de modelos manejable mientras permite la búsqueda en versiones anteriores. No estoy seguro de que el complemento maneje el encadenamiento que desea de fábrica, pero no sería difícil agregarlo.

Answer 4

Martin Fowler tiene algunos buenos artículos sobre los patrones de diseño de tiempo/a base de control de versiones - perfecto para ti:

http://martinfowler.com/eaaDev/timeNarrative.html

Answer 5

¿Qué pasa con el ahorro de una instantánea XML del shema base de datos desea versión más reciente? Y luego, ¿puedes cambiar el estado de la base de datos?