Versiones del model de dominio

Implemente el control de versiones para mi propio model de dominio (seguimiento de las diferencias en los objects durante las operaciones de actualización). El model de dominio tiene una estructura de tree. Ej. ( -> es reference)

A |-> B |-> C -> A | -> C 

Los requisitos para el control de versiones son los siguientes:

  • Obtenga el set de campos modificados entre dos versiones del object de dominio;
  • El model de dominio tiene una estructura de tree;
  • Los campos se pueden organizar en lists. En el ejemplo siguiente, el sistema debería mostrar que se eliminó el elemento Y (pero no que Z se eliminó e Y cambió su estado en Z) y X se modificó:
 [ v1 ] [ v2 ] AA |-> [X, Y, Z] |-> [X, Z] |-> C |-> M 
  • No hay más requisitos como locking / fusión / ramificación.

Investigo la forma de get un cambio establecido entre dos estados del mismo object. Trabajo con Java y me interesan los enfoques / soluciones existentes. Por ejemplo, estoy buscando la descripción del algorithm que utiliza la subversión para crear la próxima revisión.

Estaré encantado de recibir cualquier consejo teórico o práctico de su parte.

Gracias

Bueno, yo diría que hablas de 2 cosas diferentes aquí.

Subversion tiene un número de revisión para el tree completo , lo que significa que cada cambio es una copy barata de la versión anterior. Entonces, no hay un set de cambios en el término que tiene en su jerarquía de objects. Es más la sum de todos los cambios, y se calculan por file mediante su mecanismo de diferencia habitual.

Si necesita versiones para sus objects persistentes, agregaría un atributo de versión en cada uno y luego un método por class para calcular las diferencias. ¿Pero quizás necesites decirnos cómo planeas usar esa información?

Sospecho que su model de dominio no está representado con files de text, sino que probablemente sea un model de object que persiste en una database relacional. Por el momento estamos diseñando esto y ya lo hemos prototipado.

Mis lecciones aprendidas

  1. Necesita una descripción exacta de las características que necesita para el control de versiones y las que no necesita. Simplemente registrar los cambios es fácil, proporcionar versiones y twigs labeldas con locking exclusivo es difícil, proporcionando una fusión es muy difícil.
  2. El logging podría realizarse en el nivel db usando desencadenadores. Cree tablas para todos sus objects de dominio y, si se agrega / edita / elimina una input, registre la input completa. Anexar información (time …) según sea necesario. Es posible que sea necesario que cada usuario inicie session en la database como un usuario de database propio para que pueda consultar el CURRENT_USER y registrarlo.
  3. En lugar de iniciar session antes / después de las ediciones de cambios, puede registrar las modificaciones de los attributes. Pero esto creará muchas más inputs de logging y es costoso reunir todos los cambios para una confirmación específica.
  4. El locking de objects se puede hacer con llamadas a methods (locking / deslocking). La comprobación de los lockings se podría hacer en el nivel db usando detonadores nuevamente (obtenga CURRENT_USER y verifique si ha bloqueado el object). Esto tiene la ventaja de que el código de usuario no tiene que consultar si un object está bloqueado, pero la database evitará la inserción / edición / eliminación. No usar el locking requeriría que implemente una fusión. Esto será muy difícil ya que no está trabajando con files de text sino con datos altamente estructurados.
  5. Incorporar el control de versiones con su model de dominio puede ser sorprendentemente complicado. Especialmente si necesita no permitir el control de versiones de fugas en su model de dominio (si planea reutilizar el sistema de control de versiones). Prototipo!