I have asked a similar question previously back in Swift 2 and I ended up confusing myself and I don’t think I explained it very well. So i’ll aim to do a better job now
I’m building an app that just tracks how long a player has been playing in a game.
So I have a Game Model, this is where I do the tracking of the players within the game. The game must belong to a Team and from the Team, should be able to find out players. I didn’t seem to have any problem really hooking that up.
But I did when it came to saving how many minutes each player had played in that game. I wanted to be able to look back and say, “oh yeah, player x played 15 mins this game” and be able to do stats on it etc, like avg playing time over the season, that kind of thing.
And short of building a json dictionary within each
Game where the key was the name of the Player object and the time played an int
<"Payer x": 15, ...>. I couldn’t really get much further. This method seemed poor and naive, heavy on the relative code to generate it and it meant that to get a player’s whole season stats I’d need to walk through all these
Game dictionaries. Plus, I’m assuming that if someone changed someone’s name mid season (say they didn’t realize they’d spelled it wrong), they’d lose all the data as the keys would be different as they were just strings generated by the
Player.name. This didn’t sit too well with me as I know I must be wrong with that approach.
I did also consider making an intermediate entity called
gameRecord that had relationships to the Game, Player, and then store as an attribute the time the Player had played. I felt like I was combining SQL practices with Object graph though?
So, I think that I’m missing a fairly obvious idea/relation/something in how to save this kind of info. So any help with a swifty/iOS idea would be appreciated
One thing you should do is give each player entity a unique identifier. You are right names can change they can also be similar or even identical to each other. I would use a UUID string as unique ID, created when the player entity is created.
Core Data seems ideal for what you want to do, because you will want to be able to follow links to create database faults, exploring relationships to retrieve data - for example, you have entity Player retrieved by a certain UUID, you follow the player’s relationship to team to find the team (to-one relationship) they play for. You have team, you follow the link (to-many) to find out all the players of that team.
I’m unfamiliar with UDID is there a Ray Wenderlich tutorial on the subject?
How would model the saving of the number of minutes each player played in each game?
(I apologise - I just notice I had called it UDID, so that may have harmed your ability to look it up!)
It’s a pretty simple object. The idea behind UUID is that it is a long string that is unique, for all practical purposes. Without going into detail it is spectacularly unlikely that the UUID you generate is the same as one that is generated by anyone else, any time at all - so much more unlikely than a lottery win, for example, that you can call it unique.
Get one at the UUID Generator - the one in iOS is a Version 4. You can make one in iOS using UUID(), a new one is made every time.
The way you use it is to give your database entity a String member and give it the UUID’s String representation. That is then its primary key. Any name, address, pet’s age, minutes played etc. are all things you can update at will and they can be the same for multiple players - but the UUID makes each one completely unique and retrievable.
I’ll look into this. Out of curiosity then, how does Core Data internally name objects then?
Well, the main thing you need is the “primary key”. This is the thing that you can use to uniquely identify an object. So if you write a predicate where it has “key=something” then that something must be absolutely unique because you cannot retrieve a single unique user if every user may share multiple values in common, at least one must be unique to the user and that’s why I say use UDID.
Internally Core Data uses SQL. SQL has been around for decades and if you look into a SQL file with a tool (you will find the SQL file if you dig around in the simulator, for instance) you will see the messy-looking schemas and names all declared in uppercase. How it actually works internally is best left alone, not just because it’s ugly, but because thinking about how SQL works when designing Core Data can lead to optimisations that actually aren’t.