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:
filesize # can changing filesystems change reported size?
singleton # dynamically generated by beets
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?
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!