Re: more than one plist in a file.
Re: more than one plist in a file.
- Subject: Re: more than one plist in a file.
- From: "I. Savant" <email@hidden>
- Date: Fri, 2 Dec 2005 09:16:08 -0500
Unless I've completely missed the mark, the OP is correct. His
requirements are efficient and immediate log entry appending (I'm
assuming he means that the logs will become quite large), the ability
to read the data back into the app easily *and* human readability.
The reading ability would definitely be 'automagic' by going the
Core Data route. Unfortunately, the other two probably aren't going
to work together in this case.
For efficiency, he could use the SQLite store. This would make
appends quite smooth for huge log 'files'. Unfortunately, this would
render it non-human-readable.
For human readability, he could use an XML store. Unfortunately,
that throws efficiency for huge loge files right out the window.**
Appending 'events' to the XML store and immediately saving it each
time (the expected behavior of any logging system, I'd argue) could
become quite a hungry beast quite quickly, depending on how fast the
log is filled. Perhaps rotation would help (if the logs are filled
more slowly) but is not always desirable (ie, more of a pain to
'import' with other tools). But even then, it's not scalable because
if their volume ever increases, they'd be stuck finding another
solution or throwing heavier hardware at it to increase performance.
Considering this, I don't believe Core Data is a good fit in this
particular situation, with these specific requirements. (again, **)
** Note - if I misunderstood the performance issues with XML stores,
PLEASE correct me. I'd love to use XML stores for my own frequently-
saved, large data sets for exactly the same reason - human
readability (along side much more universal machine readability).
Seriously - I have no pride; I'd love to hear opinions about XML
store performance for frequent appends. You have no idea how much I
want to be wrong here. ;-)
On Dec 2, 2005, at 3:47 AM, Markus Hitter wrote:
it looks like it manages the object graph and then syncs it to a
file on demand.
... yes, exactly. Isn't this what you want?
There's a nice CoreData tutorial at CocoaDev. Chances are, you get
away with less code than if you handle your plists manually.
--
I.S.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden