• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Pattern for Versioning of Data Model

 
Greenhorn
Posts: 13
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Just wondering if anyone had any ideas for a design pattern for storing version history of a model and providing a means to view diffs on this.

We have an "application" that is submitted via our web interface and can be modifed and resubmitted later. We need a means to capture the changes each time that it is changed, then present a change report that can show the difference between each change. We came up with a few solutions - but none are that great, so I was wondering if there was a pattern for it - I'm sure this is a common requirement... or maybe I am outside the realms of design patterns here.

We are using Spring & JPA for persistence. The model is fairly complex and we only need a subset of the application to be versioned - otherwise I would probably flick it to the DBAs and get them to implement history tables. I might still suggest that approach, but still madly hunting around for other solutions.
 
Ranch Hand
Posts: 62
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

maybe I am outside the realms of design patterns here



Any established solution (the rule of thumb is "used at least three times" somewhere) to a recurring problem can be expressed as a pattern, so you're within the realms of design patterns here.

Whether or not there is actually a pattern for your problem is, of course, a different matter

I know I've run across the need to be able to version and diff models (class diagrams), but I haven't yet found or heard of any really good solutions.
 
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I worked on one application that had a trigger on update for some tables that ran a generic stored proc that compared the old record to the new one and wrote a list of individual column changes to an audit table. It was nice that the database team added the whole thing with no application changes, but the data was not in a very friendly format.

I'm starting up with another database now where we never do updates, but insert a new row and leave the old one. So far I hate the idea, but I'm going to try to keep an open mind for a while. Ok, maybe I've already failed on that.
 
Steve Dalton
Greenhorn
Posts: 13
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks for the input.

I think I will have to go with the database solution for now (for the purpose of my estimates) unless I can come up with something better in detailed design. We already have a precedent in another application where it doesn't delete data - just clones the record, puts and end date on the old one and updates the new one... so I will still with this approach.

The queries to present this data and do the diffs etc will be a bit ugly as it is spread over 2 databases and several tables, so I am investigating on using jasper - so that at least the ugly stuff is separate and easier to maintain.

Steve
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Allan Halme:

Any established solution (the rule of thumb is "used at least three times" somewhere) to a recurring problem can be expressed as a pattern, so you're within the realms of design patterns here.



Well, but we are not searching for a solution to a *design* problem here, as far as I can tell - so there might be a pattern out there that can be used to solve this problem, but it will unlikely be a *design* pattern, as far as I can tell.
reply
    Bookmark Topic Watch Topic
  • New Topic