Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Migrate storage from NoSQL to SQL (plus a little rant) #92

Open
mmontag opened this issue Sep 8, 2021 · 0 comments
Open

Migrate storage from NoSQL to SQL (plus a little rant) #92

mmontag opened this issue Sep 8, 2021 · 0 comments
Labels
enhancement New feature or request

Comments

@mmontag
Copy link
Owner

mmontag commented Sep 8, 2021

Firebase is good at all the wrong things for Chip Player JS. Realtime updates/messaging is not nearly as important as having a nice relational schema that can evolve incrementally. All Chip Player data would amount to less than 100 MB; that can be copied around and refactored locally.

User Favorites are currently stored in Firebase. It's terribly unsophisticated and I wouldn't want to build a playlist feature on Firebase.

The music catalog is completely derived from the filesystem. It does not expose any more metadata than the filename and file size. For example, it's impossible to filter on composer (which is frequently embedded inside individual file metadata) because it's not part of the filename.

The principal advantage of the filesystem is that the directory structure provides a single fixed organizational tree. This is often more intuitive and "browsable" than a collection of documents where the user has to "browse" by progressive filtering on arbitrary dimensions; i.e. a parts catalog on mouser.com that has 30 different filtering criteria. This is not browsing at all, but "narrowing." The directory structure gives the user a fixed map (directory tree) of territory to explore, while narrowing gives a map that changes based on the order in which filters are applied.

Anyway, the point is that one can maintain the directory structure metaphor even if the source of truth is a database.

Another consideration: I'm currently generating a prefix trie of the entire catalog (scripts/build-catalog.js) in order to make full-text search really fast. This optimization can also continue independent of the storage system.

Restated, there are four independent goals:

  1. Directory structure-based browsing
  2. Fast full-text search
    • accomplished with in-memory trie that resides in node.js server process
  3. Simple catalog update workflow
    • currently just a matter of adding files, then running build-catalog.js
  4. Relational data storage
    • playlists
    • query on metadata, e.g. composer, ripper, release date
    • enable "more by this artist"
    • enable playcounts

This issue is concerned with building 4 while maintaining 1, 2, and 3.

@mmontag mmontag added the enhancement New feature or request label Feb 18, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant