Question

Let me please state my scenario.

I have an application in which I would play around with some data, thats stored in the Database. For, eg: a gaming application.

1) Right now, say my app runs at version 5. At any point when playing with my app, if I feel that the currently added feature ( Feature 5 ) is not appropriate, I would like to switch back to a previous version of the application ( say, version 4 in which Features 1, 2, 3 & 4 are implemented ).

2) This means that I need a versioning system implemented at the Database level so that I could run my application with the data required for the previous version(version 4).
In simple sense, I don’t want any of the data( related to feature 5) I recently added in the production database so that I could run my application at Version 4.

3)Later, after more developments when I feel that feature 5 is stable, I would like to check in version 6 of my application and make it live.

4) Version 1, 2, 3 & 4, 5 are like checkpoints : Thats the stage when I decide that my app is good to go live. I want the capability to switch between versions and make them live as and when required.

5) Also, to clarify: A checked in version cannot be then modified upon. Which means once a checkpoint, say version 3 is set, any more changes to that version is not possible.

Please state whats the appropriate method to implement this versioning system at the database level. I have thought of a few options like, using hive to backup the data at the version point, and store as many versions of data of the application in hive. I do think this would work, but it certainly doesn’t look hunky-dorry. What I would like to know is that – Is the method what I stated a good enough option to proceed, or are there some open source application that gives me the power to version the data in my database right away? Any other suggestions or ideas are most welcome and appreciated.

Proposed Implementation:

What i do think of doing based on @Sameera’s answer.

1) Create a new versions table and relate it to the applications table.

2) Associate other tables, that were previously related to the applications table, now to the versions table.

3) Each versions table will have a state attribute 0, 1 or 2: 1 for dev, 2 for live and 0 for dead as of now.

Answer 1

I think your requirement is kinda unusual 🙂 and the proposed solution will too 😀 (Assuming i got your question right)

Following is a basic structure that I think will work

You could have a table with all the versions and links to the new features

Ex: if you add a module to pick a gun, in ver5 your link to pick a gun will be added to a table with version number

version | module 
1       | basic_game
2       |  gun

So then according to the user selected version, you load all the modules and their layouts dynamically.

By this was your users will not hit the db with new changes and you dont want to version the db. (and the other thing is even if you version the db you should have a way of controlling the code as well)

I’m not sure if this applicable to you, but this is a one solution that I could think of