Object versioning patterns [closed]

Question

I'm trying to model some of our objects in our domain and came across a problem that some of these objects could be versioned. i.e, user could create new object versions over a period of time. So, I need to model them in the program. I think that this is a common problem in SW design.

Initially I jumped to the idea of mimicing source control versioning concepts and came up with a versioned object concept and methods like check-in, check-out etc. But, I get a feeling that it is not quite 'systematic' as I didn't explore patterns (i.e, I feel like committing sins like

• I didn't cover aspects like looking for more than one solution
• looking into literature which would give me more solid references etc).

So, my current problem is that for a systematic modelling, I need to search for patterns which addresses the version modelling problem, preferrably in literature. And take the best out of it, of course.

So, I googled for such patterns and only found a Temporal Object pattern. But, I was not sure if this was really what I wanted. Do you guys have any suggestion on such patterns?

[Self-Edit] Maybe I haven't described the problem well. You can see the problem similar to a source-control file-versioning problem. I have several types of objects (stored in database) that can have several versions. Inside my application I have to handle all these versions and also I will have to create new version of objects (which will eventually get stored in database). What I'm looking forward is some kind of cite-able pattern with which I can model the interfaces for accessing/modifying/adding new versions for these objects. The basic interface I could come up with is IVersionedObject with methods like checkout, checkin, undoCheckout etc. But, this is my own idea observing source control systems. I don't think it is a SW design pattern as such. So, looking forward for some very well documented design patterns for the above problem.

Answer 1

Wouldn't something like a custom DataMapper work?

doc = DocCatalog.get( docid, version );

Assuming you can consider each object a materialization of what the object represents, at a given moment (in time). Instead of being an object with a "version" property, the "versioning" is taken care of by the datamapper/catalog/database; ie, the object doesn't know about versions, but the object storage system does.

Saving/storing an object in the datamapper would generate a new version:

// saves doc again after changing the title (which indeed stores a new version of it)
doc.setTitle ( newTitle );
DocCatalog.save( doc );

// gets a number indicating how many versions of the document exist
i_versions = DocCatalog.getVersions( docid );

// returns second-last version of the document
doc = DocCatalog.get( docid, i_versions-1 );