flexible attributes: Is the attribute empty or undefined

[dfc]

When you search for a flexible attribute it is not clear if the value is empty or undefined:

dfc@ronin:~/0xRepos/Audio$ beet list sometagthatimadeup:|head
/Passenger - Wicked Man’s Rest - Wicked Man's Rest
/Passenger - Wicked Man’s Rest - Night Vision Binoculars
/Passenger - Wicked Man’s Rest - Things You've Never Done
/Passenger - Wicked Man’s Rest - Girl I Once Knew
/Passenger - Wicked Man’s Rest - Do What You Like
/Passenger - Wicked Man’s Rest - Needle in the Dark
/Passenger - Wicked Man’s Rest - Four Horses
/Passenger - Wicked Man’s Rest - You're on My Mind
/Passenger - Wicked Man’s Rest - For You
/Passenger - Wicked Man’s Rest - Walk in the Rain
dfc@ronin:~/0xRepos/Audio$ beet list sometagthatimadeup:""|head
/Passenger - Wicked Man’s Rest - Wicked Man's Rest
/Passenger - Wicked Man’s Rest - Night Vision Binoculars
/Passenger - Wicked Man’s Rest - Things You've Never Done
/Passenger - Wicked Man’s Rest - Girl I Once Knew
/Passenger - Wicked Man’s Rest - Do What You Like
/Passenger - Wicked Man’s Rest - Needle in the Dark
/Passenger - Wicked Man’s Rest - Four Horses
/Passenger - Wicked Man’s Rest - You're on My Mind
/Passenger - Wicked Man’s Rest - For You
/Passenger - Wicked Man’s Rest - Walk in the Rain
dfc@ronin:~/0xRepos/Audio$

ore me personally there is a difference between an empty value and a ield that is not present.

[sampsyo]

Good point; it would be nice to differentiate these two cases. Any ideas for how to do this? Should special query syntax be provided for "field doesn't exist" or "field exists"? Or should field: just be false for items lacking "field" and true for items with any value in "field"?

[dfc]

I think beet list field: should match any songs that have the attribute field. They can contain a value or they can be empty. If the field does not exist nothing should be printed. I think the special query syntax needs some logic operators. So field: would print all songs with that attribute but I could do something like

$ beet list field: AND !field:""

to print a list of all songs with field defined and nonempty.

Also see #547. I think I should be able to query for empty AKA "". (I filed #547 because regardless of how you choose to implement this giving beets a "" should not cause death.)

Sidebar:

I can imagine hearing *OMG dfc you are driving me nuts!" I apologize. In case you are wondering about the end game I would really like to use the echonest flexattrs for smart mpd playlists. Plus once you have all these kinks worked out it will be that much easier to implement buuks so I can manage my pdfs/epubs as easily as you have allowed me to manage my music;)

[sampsyo]

Seems like a fine design to me, with one nit. These two commands:

$ beet list field:
$ beet list field:""

are actually indistinguishable to beets. Your shell gobbles up the quote characters before beets ever gets to see them. Perhaps what you meant was:

$ beet field::^$

which uses a regex to match empty fields.

(And: you're certainly not driving anyone nuts! These are great thoughts; thanks for contributing.)

[dfc]

$ beet field::^$

Looks good to me. The field:"" was a brain fart. Will field:\"\" work for empty strings? I have not updated my beets with the fix for the bpm:"" bug yet. Right now bpm:\"\" gives the same error as bpm:""

I am glad that you are not sick of the issues yet. I am about to start on typing up the big one: supporting the JSON API for Live Music from archive.org for file metadata AND direct importing. They have terabytes of awesome music freely available with great metadata as well as numerous different formats of the same song/album/show.

[sampsyo]

Cool. And no, not at the moment: field:\"\" will find matches that contain two double-quote characters right next to each other. (We don't currently parse quotes ourselves; we just leave that up to the shell.)

That sounds great! I'm not familiar with the API, but it seems like a natural extension.