Whether or not a song is covered, there was an original artist who originally performed the song. The only issue is that an Artistsongs table will almost be the exact same as the Albumsongsartists table, since most songs aren't covered. So, it may be better not to populate that table by default, and then if two albumsongs with different artists share the same song, then fill the Artistsongs table.
The birthday paradox is a real problem with the size of our datasets. i64 is the largest numerical value we can use, and there's a 0.1% chance of collision with ~2,000,000 values, so I feel pretty comfortable with this
This can (will) be easily replicated for the other views, I just first tested it on songs. I think this looks much nicer, and I'll probably roll with a layout similar to this for the other views, with some minor adjustments for each particular view.
This also makes the entity_info struct very similar to the UnifiedResult struct, so we'll probably see a merge at some point. Would be nice if we used the fields from the entity_info result more commonly.
One of the largest components that makes zuletzt unique - implementing groups the way MusicBrainz has (release groups in particular). I thought for a while that I would just connect songs via a shared ID, but for remixes and such, I don't think they should be so tightly coupled. This also gives the user freedom for how they want to do the grouping (a remix can be included in the group if they choose to, or it may not). This will allow someone to see a combined scrobble number for an album with, for example, a regular release, a deluxe release, and an anniversary release, in addition to the individual releases. This will complicate SQL queries rather significantly I imagine, and I'm not sure what the interface for creating/deleting groups will be (although it will likely be easier when I have full use of TS), but it's a necessity for the project.
Adds datestreak query, provides the number of songs/albums when relevant, and provides timescale with all years, regardless of the number of plays (defaults to 0)
If I can figure out a way to get an array of a union instead of a union of arrays, we're in business to make this even better, but this is fine right now. The inline else was just a dumb way to keep the for on the outside
I have been unhappy with the branches, but didn't quite know what to do about it. THis feels much nicer. Also fixes datetime stuff with jetquery. The HTML element parsing isn't quite where I want it to be, but it works for the time being.
I was making them unnecessarily large by accidentally storing them as microseconds instead of milliseconds. Might be able to get away with seconds in the future
