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)
    sha1:        data
    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 SaveState {
    game:       u64
    name:       string
    date:       date
    preview:    url?
    path:       url?
}
 
 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)
}

[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?
• Save State Management #26
• Collections #27
• Control Bindings
• Settings
• Proper error handling
• And – down the line – CloudKit integration.

[magnetardev]

Looking into more optimal ways of doing things, i.e. where are Core Data supposed to be ran? Just any actor/task queue?

Pretty much everything storage-wise will need to be redone. A custom executor can make Core Data support something akin to SwiftData's ModelActor.