[Feature Request] Label as multi-enum

I’m guessing this is a no-go simply due to data risks (though, hey, single selection → multiple is less risky than plenty of other conversions…right? =), but having label as a forced single field sidesteps the reality that many, many releases are co-releases, collaborations, or otherwise released by >1 label.

It’s a bit of clutter and a touch of data anti-hygiene to end up with, say, “Atlantic/Rhino” as well as Atlantic and Rhino (plus the possibilities of ending up also having “Rhino/Atlantic”—to say nothing of “Atlantic, Rhino”, “Atlantic; Rhino” and so on).

I always see the value of these kinds of data fields as being a way to look for everything released by a label, or to see what label might dominate in a collection, or some variation on these—both of which are rendered impossible with a single datafield and multiple labels involved (in Collector only, you can always do a filter by “contains ‘$LABEL’”, of course, but that takes knowing some RegEx to avoid pulling in, say, “Anticon” alongside "Anti"¹—and I’ve been told by enough people that enjoying RegEx is a sign that something is wrong with me…)

But nothing ventured, nothing gained, right? It definitely won’t happen if I don’t ask, even if it won’t happen if I actually do as well.

¹Which should be—and usually is, as far as I’ve seen—“Anti-”, which saves the issue, but the principle stands, even if that wasn’t the perfect example

I would love to see this as well. I have scores of vinyl reissues that have the original release label and a reissue label. Since we have two release date fields, release date and original release date, it only makes sense to have two label fields to go with them.

I’d go even further to a “checkbox list” like we have for Studios, etc, just because it can go past two panels, but a second one wouldn’t go amiss as a backup!

2 Likes