Writing to the database via a plugin

[Drew]

I know that it is possible to extend MediaFile and write custom metadata to music files, but I would like to know if there is a way to add a column to the beets library and write to it.

I'm writing a Google Music uploader plugin, which would (optionally) save the Google Music ID of uploaded songs to a database so that it would be possible to only upload new songs.

To be honest, I'm not sure whether or not writing to the beets database is a better option than writing directly to music files using MediaFile. I'm a little bit wary of writing a plugin that has fairly important functionality that requires the modification of the user's music files.

-- Drew Walter

[Adrian Sampson]

Hi, Drew -- first of all, this sounds like an awesome plugin. I'd totally use it!

Interesting that you should ask about adding arbitrary information to the database from plugins. A few of us have been hacking on a design to make this possible over the last couple of weeks and the feature (which will be a major change for 1.2) is nearly ready. Most of the discussion has been going on in this thread:

https://github.com/sampsyo/beets/pull/101

The feature, currently called "flexible attributes", lets plugins add arbitrary namespace/key/value triples to Items and Albums in the database. This has all manner of cool use cases, likely including yours. Let me know if you think this system will suffice for your purposes.

Adrian

--
You received this message because you are subscribed to the Google Groups "beets" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beets-users...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Drew]

Adrian,

That sounds like it's exactly what I need! I'll keep an eye out for 1.2 betas, thank you!

-- Drew Walter

[michael....@gmail.com]

On Wednesday, April 3, 2013 12:26:40 AM UTC+2, Adrian Sampson wrote:

[...]

https://github.com/sampsyo/beets/pull/101

The feature, currently called "flexible attributes", lets plugins add arbitrary namespace/key/value triples to Items and Albums in the database. This has all manner of cool use cases, likely including yours. Let me know if you think this system will suffice for your purposes.

 

I've looked at the discussion, admittedly not overly thoroughly. My first reaction to "flexible attributes" (or EAV, entity-attribute-value pattern for some) is that I don't much like it. At least not for use cases I have in mind (more below). My preferred overall approach would be a normalized schema with views (+ INSTEAD triggers) standing in for the current items and albums tables. In addition, I'd like to see a way for plugins to define their own tables.

I'm in favor of normalization mostly because of data integrity. I don't think(!) concerns of storage size and query performance are relevant given the essentially trivial amount of data we're dealing with.

When I found beets a couple of weeks ago, I was looking for a way to create playlists based on all artists participating in a recording. Let's say I want to create a playlist for Steve Morse. Off the top of my head, I'd have to look at albums by himself, the Dixie Dregs, Kansas, Deep Purple, Flying Colors. The thing is, I don't want to use my head for that and I see beets as a piece in the toolkit I need to get there. Another piece is, that as far as I can tell, discogs.com has a lot of the information I'm looking for.

So my mid-term target is to write a beets plugin that attaches discogs data to my beets library. However, it would be unwieldy to map that data to key-value pairs. And it would be downright nasty to query it.

Michael

[Adrian Sampson]

> I'm in favor of normalization mostly because of data integrity. I don't think(!) concerns of storage size and query performance are relevant given the essentially trivial amount of data we're dealing with.

I agree that the size and performance differences for these approaches are not too important even for the largest of music libraries. The reason I'm currently favoring a denormalized approach and a key/value model is for conceptual simplicity: for the vast majority of cases, this is exactly what's needed and more complexity will impede development.

> When I found beets a couple of weeks ago, I was looking for a way to create playlists based on all artists participating in a recording. Let's say I want to create a playlist for Steve Morse. Off the top of my head, I'd have to look at albums by himself, the Dixie Dregs, Kansas, Deep Purple, Flying Colors. The thing is, I don't want to use my head for that and I see beets as a piece in the toolkit I need to get there. Another piece is, that as far as I can tell, discogs.com has a lot of the information I'm looking for.

This sounds like a really interesting use case and you're right that a more complex schema might be appropriate here.

Note that beets' current preferred source of music metadata, MusicBrainz, also has the information you're looking for. See Steve Morse's "member of" relationships here:
http://musicbrainz.org/artist/6f0d1ab4-a0b8-4d59-acda-5fe3b63058f0/relationships

It sounds like you're interested in queries over the full sophistication of the MusicBrainz data model. That's an exciting prospect, and something I'd be interested in exploring, but it's different from the limited kinds of schema extensibility that 1.2 will bring.

Adrian

[michael....@gmail.com]

On Sunday, April 21, 2013 9:36:45 PM UTC+2, Adrian Sampson wrote:

[...]

> When I found beets a couple of weeks ago, I was looking for a way to create playlists based on all artists participating in a recording. Let's say I want to create a playlist for Steve Morse. Off the top of my head, I'd have to look at albums by himself, the Dixie Dregs, Kansas, Deep Purple, Flying Colors. The thing is, I don't want to use my head for that and I see beets as a piece in the toolkit I need to get there. Another piece is, that as far as I can tell, discogs.com has a lot of the information I'm looking for.

This sounds like a really interesting use case and you're right that a more complex schema might be appropriate here.

Note that beets' current preferred source of music metadata, MusicBrainz, also has the information you're looking for. See Steve Morse's "member of" relationships here:
http://musicbrainz.org/artist/6f0d1ab4-a0b8-4d59-acda-5fe3b63058f0/relationships

It sounds like you're interested in queries over the full sophistication of the MusicBrainz data model. That's an exciting prospect, and something I'd be interested in exploring, but it's different from the limited kinds of schema extensibility that 1.2 will bring.

 

I noticed that beets relies on Musicbrainz data and that would have been my first idea, too. However, my first impression was that Discogs has much more detailed data. I looked again just now and it seems I was mistaken. In general, I'm looking for metadata for individual tracks, not albums. Album data might work for rock, but for jazz and classical the lineup can be rather different for each track.

I'm not going to start work on any of this tomorrow as I have other personal projects. I'd be happy if I have something working by the end of the year and in the meantime I keep my eyes open for workable options.

Michael