64bit/Database/Stores

goal: to have downloading and installing each music store database be very fast

current design:

1. store songs are marked as such, that way when we load the database, if the user has "turned off" a particular store, we can just purge all song entries associated with that store
2. kjams downloads an xml or json file for a particular store
3. kjams parses each song in the downloaded. for each song, create a brand new song ID, start a transaction, then parse each bit of metadata (table colums) and adds each to the DB as an individual call to sql, then when the song is completed, checkpoint the transaction. this is an extremely slow process
4. this may be happening for up to N stores at once, each on a different thread, and gets slower as more stores are parsed at once due to database locking
5. when entire store has completed parsing, we must then associate each song with an existing song (swap the newly created ID of the song with the existing song ID, that way any playlists that already have that song in it will now reference the new song with possibly updated meta data. after all songs are done, purge all NEW song IDs (since they were swapped with old song IDs, we're actually purging the old songs, keeping the new ones with the old IDs

new design:

1. a special version of kJams runs on my Server, and, while doing all of the above, saves each store into a SEPARATE SQLite database file.
2. my server then makes these (optionally zipped) sqlite db files available
3. user kJams downloads the sqlite file from my server. if it is NOT available, it falls back to doing what it does today
4. kJams loads the store sqlite file and merges it into the existing Library. note the SongID stored per song in the store is ONLY unique within each store, and may conflict with SongID of Library once loaded: while loading we must give each record a new ID
5. pick up at step 5 above