GSOC Proposal for Storage for AcousticBrainz v2 data

[sweta05]

Here is my proposal This is a part of my proposal @alastairp I would grateful if you could check it and clarify some of my doubts as well.
Firstly please excuse my bad formatting I will change it soon.
Secondly, I have some doubts listed below please clarify them.

@sweta05

Query
ALTER TABLE version ADD COLUMN extractor_version DEFAULT="music 1.0";

Do we need a default or can we assume NULL to be the old version?

@sweta05

While trying to evaluate the dataset with recording having data of new extractor version
Check if enough data are available for training the model. (select a limit to say 10000 entries)

• Case I: If a significant number of the songs in the dataset don’t have data for the new version.
  • Display message to the user that “not enough low-level data(new extractor version) available” and give a choice to the user

What should be the most optimal trigger for giving the user the option to go with old version data?

@sweta05

• In the client initialization check version of the extractor
  send extractor version to the server to check compatibility
  if the response from the server is TRUE then proceed with normal
  else stop the further flow and show message received from the server

Any inputs on how we can get the version of the extractor in use at the client before running the extractor to avoid unnecessary computation? (instead of retrieving it after extraction)

@sweta05

Update SQLite table schema

The client uses an SQLite database to store the entries of submitted files
We can add a column of version and check it before evaluation and make sure the previous ones used the latest version if not allow them to get submitted.

When releasing a new version of client-side software are we going to update or download the new client software? This point can change a lot of implementation details i have listed below.