CODEWITHSUNDEEP
database-designresponsiveindexeddb
sam
sam

Reputation: 340

Using indexeddb as a versioned database with multiple versions

Scenario:

You create an excel sheet in 2018. It has lookup tables in sheets. Let's call this DB ver 1. User submits the excel as a form-Form ID 1. Now in 2019 you update the lookup tables and publish a new version of the excel. This is now DB ver 2. User submits latest 2019 excel as a form -ID 2.

Now try doing this in a web application. We are using Rule.JS, Formula.JS and JS promises along with indexed db to mimic excel like functions. We are using indexeddb to avoid the multiple calls to the db for lookups. So only STATIC data is stored in indexeddb. All this works when work with the latest data. My design challenge is to do this for older forms that might need to use old versions of the db lookup tables.

When you open Form Id 1 in the browser- Db ver 1 should be loaded.

When you open Form Id 2 in the browser - Db ver 2 should be loaded.

Problem:

  1. Can indexeddb be used to load a specific version on page load using the indexedDB.open(dbname,ver)?
  2. Can indexeddb version be downgraded on page load?
  3. Can we pass the version# as an argument from JS on page load?

The problem is that each form needs to pull a specific version of the the Db based on when it was submitted. Using indexedDb, i understand that it is a forward looking database. So we can only upgrade to a newer version and not downgrade. Is there a way to do this with indexeddb or am i barking up the wrong tree?

One solution i came up with is to create two tables in SQL. 1 actual table, 1 archive table. Each time the data is updated, we move the old data to the archive table with the version #. If the form is looking for a specific version, the GetData(lookupvariable, ver#) can search either table to find the value for that specific version. This way, i will have to eventually convert everything to an AJAX call and do away with indexeddb.

Upvotes: 0

Views: 731

Answers (1)

Raymond Camden
Raymond Camden

Reputation: 10857

An IDB datastore named foo will have the same data no matter what the version. So if you add data in v1, then change it to v2, the data doesn't go away. IDB uses versioning as a way to let you change the structure. You can only modify object stores when the version changes.

So I'd say yes - you are barking up the wrong tree here, using versioning as a way of partitioning data. I think your solution of an archive table actually makes much more sense.

Upvotes: 1

Related Questions