Beets null fields vs empty fields

#1

I’ve had beets complete processing a subsection of my library and afterwards took a look at the items table and ran a few queries against it. I noticed that the composer field (and presumably same applies to other fields) fails a IS NULL condition when there is no composer entry present in the record so the test becomes
composer != ""

Is there a reason that fields without values aren’t left in a null state when records are written to beets tables?

@adrian: Would my running an UPDATE query to set all ="" to NULL break anything within beets’ logic? Reason being I’ve previously written merge code to update my own database (which is based on my curated file tags) and bring in only data from records where the corresponding field of the associated record in my table is NULL. Rather than modify my code wherever a query references the NULL condition it’d be easier to set empty fields to NULL in the beets tables.

#2

Inside beets, we try pretty hard to avoid nulls (i.e., Python None) in the core data model. More generally, we try to keep the types consistent—if the artist field holds strings, then item.artist is always a str; never None. This is a really important invariant that makes the code simpler than it would be if it had to constantly consider whether a field was null or not.

It’s hard to say what would happen if you manually edited the SQLite database to inject NULL values. Things will probably mostly work; our database layer does coercion that translates nulls into empty values in most cases. It’s worth trying it to find out.

If you’re curious about how all this works, take a look at beets.dbcore and especially its types module.