I’m working on a test in support of this. I want to test that only a whitelist of fields can change between moves. I have a few that I’m not sure about:
item fields:
filesize # can changing filesystems change reported size?
id
initial_key
singleton # dynamically generated by beets
album:
added # date added - static?
Interesting… could you elaborate a little more on what you’re imagining changing when a file moves? For example, I’m not sure why initial_key would change when a file moves. I guess it’s probably true that the file size could change when moving between filesystems… but I guess I would hope that beets wouldn’t need to worry about that somewhat strange possibility?
Interesting… could you elaborate a little more on what you’re imagining changing when a file moves?
That’s just it - almost all fields I assume don’t change. I’m trying to whitelist the few that do and build a test for the rest.
fluid_item_fields = [self.i.path, self.i.mtime]
fluid_album_fields = [self.album.path, self.album.artpath]
fluid_fields = fluid_item_fields + fluid_album_fields
I don’t know what these fields are and especially don’t know how they are implemented. So I’m asking. There’s no documentation explaining all the fields, is there?
https://beets.readthedocs.io/en/stable/changelog.html?highlight=initial_key#april-15-2014
Okay, so initial key is out. item.id is the internal beets ID for an item? Would that ever change in a move?
Alright—I guess my default assumption would be that no fields change on a move except for path, which by definition must change because that’s the thing that’s changing. 
I’d definitely start with that assumption and go from there.
However, there’s a chance I’m missing something… let me know if you run into trouble with that assumption!