Storage

[magnetardev]

Psudeo-code of some of the tables/general storage stuff we'll need:

table Game {
    id:         @unique(u64)
    name:       string
    system:     GameSystem
    boxart:     ImageRef?   // this should be a URL of some kind, ideally local (but NSCache exists so that may not be an issue)
    md5:        string      // ROMs will be
    dateAdded:  date
    datePlayed: date?
}

table Cheat {
    id:         @unique(u64)
    game:       @foreign(Game.id)
    name:       string      // user-picked display name
    enabled:    bool
    format:     string
    code:       string
}

 table ControlBindings {
    id:         @unique(u64)
    auxId:      string      // auxiliary identifier, this is really just used for the controller id
    kind:       ControlBindingKind
    touch:      @foreign(TouchControlBindings.id)?
    gamepad:    @foreign(GamepadControlBindings.id)?
    keyboard:   @foreign(KeyboardControlBindings.id)?
}

table TouchControlBindings {
    // TODO: this is a pretty complex storage type...
    id:         @unique(u64)
}

table GamepadControlBindings {
    // TODO: this is a pretty complex storage type...
    id:         @unique(u64)
}

table KeyboardControlBindings {
    // TODO: this is a pretty complex storage type...
    id:         @unique(u64)
}

// TODO: should this be a table? most of the info can be pulled from the file system.
table SaveState {
    game:       u64
    name:       string
    date:       date
    preview:    url?
    path:       url?
}

• ROMs will likely be associated with the MD5
• Saves will likely be just be named "\(gameId).save.\(saveExtension)"

[magnetardev]

Okay, so pretty much everything here besides controller bindings and settings is figured out:

• Game
• SaveState
• Cheat
• Collection
• ImageAsset

It really just needs a more unified API so that core data stuff is more or less abstracted away, which will likely help streamline CloudKit integration and also help if we migrate to something like SwiftData down the line.

Controller bindings could probably just be stored as the following, where the data field is a codable-encoded representation of the bindings.

id:         UUID
auxId:      String
system:     GameSystem
game:       Game?
kind:       ControlBindingKind
data:       Data

Settings is a bit trickier and I'm not really sure what to do about them. The basic settings could just be tossed into UserDefaults, but game-specific settings would be a nice feautre as well as core-specific settings. Here's the basic stuff I've had in the back of my mind:

• Core settings would more or less be a dictionary, cores specify settings with ids and value types.
• Games could point to core settings (though that may be unnecessary since most cores will only have settings for BIOS files)

[magnetardev]

Okay so I've centralized a lot of the APIs and I think everything Core Data related is now abstracted in a reasonable way.

I've also made two big improvements:

• Use cascading deletes for most Game relationships.
• Move associated file system deletes into the NSManagedObject.prepareForDeletion method.

Those two things will improve data consistency substantially, and this applies for the three entities where it matters: Game, ImageAsset, and SaveState.

Now that the API is cleaner, the remaining storage-related things are:

• [ ] Looking into more optimal ways of doing things, i.e. where are Core Data supposed to be ran? Just any actor/task queue?
• [x] #26
• [x] #27
• [ ] Control Bindings
• [ ] Settings
• [ ] Proper error handling
• And – down the line – CloudKit integration.