Re: More Core Data Questions
Re: More Core Data Questions
- Subject: Re: More Core Data Questions
- From: Jon Hull <email@hidden>
- Date: Tue, 13 Oct 2009 03:17:28 -0700
The project is a game engine which has 2 graphs. The first is a tree
of events that represent the story. Each "event" in the story is an
immutable object, and there is a special event which represents a
series of events to run in order and one which represents branches
that the player has to choose from. All of these are immutable, and
the main goal is to avoid loading the whole graph which will consist
of 10k-50k events. This graph will be the same for every player.
Okay. If you build this immutable store on your dev machine and
include it in your project resources, you should see excellent
performance. Creating a store this size on the device would take a
while. Just don't go crazy with to-many relationships or database
normalization (for this many objects, on a phone).
Of course, you don't want to search across all the events all the
time. You'll want some criteria (NSPredicate) to evaluate just the
subset of relevant elements.
Yes, I plan to have an editor which creates the file on my Mac, and
then include it with my resources for the iPhone project. The only
real search-ish type thing I need to do at the moment is finding an
Event by it's id.
I also use proxies as context switches to objects in this
graph. A concrete example is the current location, which is a proxy
that pretends to be a location, and forwards all the messages it
receives to the location object where the player is currently
located. This allows events which reference locations/players/etc
that change depending on state to remain immutable.
You don't need proxies or NSProxy for this. You can just use a
delegate. Off the cuff, I might consider implementing a protocol on
your immutable objects for methods like "currentLocation" and
"currentPlayer" which vector through a semi-global context object
not unlike the app delegate. Then you can use keypaths to naturally
write currentPlayer.name and so forth. NSProxy is unnecessarily
heavy weight for simple delegation. They use memory too, ja know.
And the semi-global context allows you to avoid making all your
objects larger. You might even model the "current state" as a
formal entity. That buys you change tracking, undo, multi-writer
conflict resolutions and the ability to easily persistent and search
for it. It also allows other managed objects to work with it
naturally.
Hmm... something to consider. The proxies do allow some powerful
runtime state effects. The currentLocation was just a simple (and
often used) example, but it is easy to have proxies which represent
"The sister of the person I am currently talking to" or the location
of that person or the item which that person holds in their hand.
They can also be used to represent groups of characters. This is very
powerful, and has come in very useful. Still, it might be possible to
get the same functionality in another way.
Luckily, the architecture of the engine has allowed me to make major
changes rather painlessly so far. Part of the reason that I used
proxies in the first place is that it allowed me to keep proper
encapsulation. I will have to think on other ways to get the same
behavior while maintaining the overall architecture/extensibility.
I have a
controller set up which communicates with the main thread, and the
background thread blocks until the controller gets a valid response,
at which point it starts unwinding again until it needs another
response or reaches the end. There is no run loop for this thread.
sure. don't forget an autorelease pool.
Yes, I create/destroy a pool for each nested array of events
and then call off to the manager with the id whenever they need to
run an event. Inside
the manager I would either call off to a small sql database with
blobs
holding freeze-dried (keyedArchiving) objects & an id column,
not a great plan. No searching into blobs, no partially loading or
saving the larger freeze dried objects.
hmm... The largest blob would probably be an object with an array of
20 or so pointers/ids. Not sure I need to search into them... mostly
I just need to grab them by id.
I had considered just using core data for everything, but as I
mentioned in a previous post, I *need* to have consistently ordered
arrays of these immutable objects (which can be in multiple places in
a single array, and can be in multiple arrays). This is apparently
difficult using core data :-(
Although, now that I think about it, perhaps I can store *just* the
array of ids as a binary property, and have everything else defined in
the entity. I will have to do some experiments.
Also, you could do that trivially with Core Data and just be done.
Do you mean store the blobs in a core data managedObject instead of a
SQL database? or avoid the blobs entirely using core data?
or save each event as a file with the id in the filename.
Each event file would have to be > 8K before this even begins its
distant journey to approach making any sense at all from a
performance perspective.
Good point. None of them are even close to that size.
Thoughts? Does this sound like a reasonable approach,
Not really, no. Maybe you need to do something quick & very dirty
for deadlines. c'est la vi
Thank god I am 2 weeks ahead of schedule. I expect that this might
significantly eat into that lead though...
or will core data actually work for me?
It's not clear to me why you think it wouldn't. So far, all I get
is that you haven't used Core Data before and don't know it. Which,
btw, is a perfectly valid issue to be having as you consider
bringing a previously designed project to deployment . Major
changes in technologies are generally best saved for major
versions. Also known as the "if it's making money, don't **** with
it" principle.
Yeah. I have only used it for simple models. This one is quite
complex, and requires a better understanding of the internals of core
data than I currently have.
Unfortunately, it sounds like you don't have a ready alternative
besides to spend a considerable amount of your own engineering
resources. You'll have to decide if learning Core Data, and tuning
your app performance fits within your schedule requirements, and
whether implementing, debugging, and tuning all this yourself will
really take any less time.
You might consider mocking up a Core Data version over a few days
and seeing how far you get.
Yes, I think I will try that.
Any advice on how to handle the 2 different types of graphs mentioned
in my earlier post? Ideally I should have 2 files. One holding the
event tree and one holding the rest (i.e. the stuff that changes).
They main problem there is that they have connections between each
other (e.g. an event might take a location or character as a parameter)
Thanks for your clear and thoughtful response,
Jon
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden