Re: Opinion: Core Data or roll my own?
On Apr 8, 2014, at 5:31 PM, BareFeetWare list.develo...@barefeetware.com wrote: One option is to use SQLite. I've been putting together an open source BFWQuery library to hopefully simplify the whole thing, by letting you treat a database query just like an array of dictionaries. It uses FMDB (thanks Gus). eg: query.resultArray[row][columnName] Here is an example: ... to just get row 3's value for Name: query.resultArray[3][@Name]; That's all there is to it. Behind the scenes, BFWQuery only retrieves rows from the database as requested, so it doesn't create an in memory array containing all of the results. On 9 Apr 2014, at 12:38 pm, Jens Alfke j...@mooseyard.com wrote: Watch out: I have found this degree of abstraction to become a major performance bottleneck. It results in large numbers of object allocations and message-sends during query evaluation. Very good point. One of my objectives with BFWQuery is avoid extra object allocations. The resultArray object is a subclass of NSArray, to make it simple for the average Cocoa programmer to use. Behind the scenes, it doesn't allocate objects in an array, but fires off the needed SQLite calls when an actual object is requested. The query API in FMDB itself is more efficient, and I think clearer, although not perfect. FMDB is great at providing an Objective-C wrapper for SQLite, but you still need to know how to deal with SQLite's results (eg get the next row from a result until exhausted). In my current usage I make sure to only use the numeric-indexed accessors (i.e. get column 2 rather than column “Latitude”) because they’re much faster. That's interesting. I'll have to try some performance benchmarks and see if I can make that faster, if needed. In the meantime, BFWQuery also allows you to specify the column by number, which calls the same FMDB method that I think you're using, eg: query.resultArray[3][2]; // row 3, column 2 Thanks, Tom Look for me at WWDC 2014 Tom Brodhurst-Hill BareFeetWare -- iPhone/iPad/iPod and Mac software development, specialising in databases develo...@barefeetware.com -- Follow us on Twitter: http://twitter.com/barefeetware/ Like us on Facebook: http://www.facebook.com/BareFeetWare ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Opinion: Core Data or roll my own?
On Apr 8, 2014, at 10:07 PM, Rick Mann rm...@latencyzero.com wrote: Well, if I were to do this, one of the reasons would be to create a text representation that could be easily diffed. I took a look at Core Data's XML format, and while necessarily verbose, it would work pretty well, until the schema changed. You can always write some code to export the database to XML for such purposes. But for regular storage, SQLite, or even a binary-format flat file, is going to be a lot more efficient than XML. (Assuming you have a large data set.) —Jens ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Opinion: Core Data or roll my own?
On Apr 9, 2014, at 07:49 , Jens Alfke j...@mooseyard.com wrote: You can always write some code to export the database to XML for such purposes. But for regular storage, SQLite, or even a binary-format flat file, is going to be a lot more efficient than XML. (Assuming you have a large data set.) Oh, I absolutely agree (which is why in my original post I said I abhor text formats). But for the purposes of source control, it has to be the main file, not some export, that's text. Ideally, my app would have a domain-specific diff tool built-in, allowing for a nice binary file, but that's a lot of work! ;-) -- Rick signature.asc Description: Message signed with OpenPGP using GPGMail ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Opinion: Core Data or roll my own?
On Apr 8, 2014, at 4:20 PM, Jens Alfke j...@mooseyard.com wrote: I’m not a big fan of Core Data, but if you’ve worked with it before I suspect you’ll find it more efficient to use it for this than to roll your own. Even if you haven't worked with it before, it'll still probably wind up being more efficient to use it―as long as you're not completely new to Cocoa and your specific use case isn't fighting the framework. I've often seen rolling one's own object graph management and persistence result in gradually redoing all of the work that went into Core Data. Turns out Core Data has the design it does for a reason… -- Chris ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Opinion: Core Data or roll my own?
Depends. Why are you “fighting” Core Data? Mike On Apr 8, 2014, 3:13:12 PM, Rick Mann rm...@latencyzero.com wrote: This may prove to be an unproductive question to pose, so I apologize in advance. I'm generally a big fan of Core Data, but I'm developing a moderately complicated CAD app with libraries and design documents and such, and beginning to wonder if it would be easier to do if I weren't fighting Core Data. I'm wondering what the tradeoffs might be. If I were to dump Core Data, I'd keep the entire object graph in memory all the time, writing it out completely each time. I'd probably write XML, or some other text-based format (as much as I abhor text-based formats) because of the ease in diffing changes and using it with source control. As I write this, I realize that I can't just keep a whole document in memory; the library (which would be a collection of separate files on disk, but presented as a unified collection of content in the UI) could be very large and I'd rather not load in the whole thing. Nevertheless, I think that's doable. I'd have to handle relationships myself, but all the data types become easier to manage (I use a lot of C structs, well, really C++ structs). Thoughts? Thanks! -- Rick - signature.asc, 211 bytes ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/mike%40instantvoodoomagic.com This email sent to m...@instantvoodoomagic.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Opinion: Core Data or roll my own?
Well, one of the issues is the data types. It's a bit clunky, but workable. There's one type of entity I want to create, a Properties table that maps strings to arbitrary value types. This would be trivial if I managed it myself, but Core Data doesn't let me have an entity attribute of type id, AFAIK. The other problem I'm facing, which is probably due to me misunderstanding NSPersistentDocument, is that I want my Library document to always autosave (in the sense that it programmatically saves after changes like adding a new Part object, rather than presenting the user with a save sheet). I haven't quite figured out how to do this. There are the saveToURL: methods, but what URL? It was opened from a file, it should know that. I just want to persist changes and clear the dirty state. Maybe I'd have the same issues with a regular NSDocument. The other thing (I meant to mention in the original email) is that I can't take advantage of autosave and async file operations, etc. BUT: Do I lose a lot of undo support? I've never tried to implement undo without Core Data. On Apr 8, 2014, at 15:15 , Mike Manzano m...@instantvoodoomagic.com wrote: Depends. Why are you “fighting” Core Data? Mike On Apr 8, 2014, 3:13:12 PM, Rick Mann rm...@latencyzero.com wrote: This may prove to be an unproductive question to pose, so I apologize in advance. I'm generally a big fan of Core Data, but I'm developing a moderately complicated CAD app with libraries and design documents and such, and beginning to wonder if it would be easier to do if I weren't fighting Core Data. I'm wondering what the tradeoffs might be. If I were to dump Core Data, I'd keep the entire object graph in memory all the time, writing it out completely each time. I'd probably write XML, or some other text-based format (as much as I abhor text-based formats) because of the ease in diffing changes and using it with source control. As I write this, I realize that I can't just keep a whole document in memory; the library (which would be a collection of separate files on disk, but presented as a unified collection of content in the UI) could be very large and I'd rather not load in the whole thing. Nevertheless, I think that's doable. I'd have to handle relationships myself, but all the data types become easier to manage (I use a lot of C structs, well, really C++ structs). Thoughts? Thanks! -- Rick - signature.asc, 211 bytes ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/mike%40instantvoodoomagic.com This email sent to m...@instantvoodoomagic.com -- Rick signature.asc Description: Message signed with OpenPGP using GPGMail ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Opinion: Core Data or roll my own?
On Tue, 8 Apr 2014 15:24:19 -0700, Rick Mann said: but Core Data doesn't let me have an entity attribute of type id, AFAIK Sure you can, that's what 'transformable' attributes are. Your custom object would need to be able to serialize/deserialize itself via NSCoding to be able to persist itself though. Cheers, -- Sean McBride, B. Eng s...@rogue-research.com Rogue Researchwww.rogue-research.com Mac Software Developer Montréal, Québec, Canada ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Opinion: Core Data or roll my own?
On Apr 8, 2014, at 15:42 , Sean McBride s...@rogue-research.com wrote: On Tue, 8 Apr 2014 15:24:19 -0700, Rick Mann said: but Core Data doesn't let me have an entity attribute of type id, AFAIK Sure you can, that's what 'transformable' attributes are. Your custom object would need to be able to serialize/deserialize itself via NSCoding to be able to persist itself though. Oh, maybe you're right; that would work if I just coded up my class's property as id, wouldn't it? Don't know why I thought that wouldn't work. That's what I get for working on this project after 10 hours of coding at my day job, I guess. -- Rick signature.asc Description: Message signed with OpenPGP using GPGMail ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Opinion: Core Data or roll my own?
On Tue, 8 Apr 2014 15:47:21 -0700, Rick Mann said: Oh, maybe you're right; that would work if I just coded up my class's property as id, wouldn't it? Don't know why I thought that wouldn't work. For example, we have a class that represents a 4x4 matrix. It conforms to NSCoding to serialize itself. In the xcdatamodel, when we want to use one of these objects, we set the attribute type to 'transformable'. As we also use mogenerator (which I strongly recommend), we set in the user info dictionary a key of 'attributeValueClassName' with value 'MyClassName', then mogenerator will make accessors with the right types too. Cheers, -- Sean McBride, B. Eng s...@rogue-research.com Rogue Researchwww.rogue-research.com Mac Software Developer Montréal, Québec, Canada ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Opinion: Core Data or roll my own?
On Apr 8, 2014, at 3:13 PM, Rick Mann rm...@latencyzero.com wrote: As I write this, I realize that I can't just keep a whole document in memory; the library (which would be a collection of separate files on disk, but presented as a unified collection of content in the UI) could be very large and I'd rather not load in the whole thing. Nevertheless, I think that's doable. In my experience (and I’ve done this at least three times), creating an object model that can be “paged” in and out from disk is hard, and takes more development time than you think it will. It may not seem hard to get it mostly working, but you keep having to come back to it to fix bugs or handle edge cases. I’m not a big fan of Core Data, but if you’ve worked with it before I suspect you’ll find it more efficient to use it for this than to roll your own. —Jens ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Opinion: Core Data or roll my own?
using NSDocument w/ autosaves is a great way to go—lots of bang for your buck! xml could open possibilities in terms of web potential. moving history into your model will better facilitate portability [in case you’re thinking in this direction]. all good things for a cad app. On Apr 8, 2014, at 6:24 PM, Rick Mann rm...@latencyzero.com wrote: Well, one of the issues is the data types. It's a bit clunky, but workable. There's one type of entity I want to create, a Properties table that maps strings to arbitrary value types. This would be trivial if I managed it myself, but Core Data doesn't let me have an entity attribute of type id, AFAIK. The other problem I'm facing, which is probably due to me misunderstanding NSPersistentDocument, is that I want my Library document to always autosave (in the sense that it programmatically saves after changes like adding a new Part object, rather than presenting the user with a save sheet). I haven't quite figured out how to do this. There are the saveToURL: methods, but what URL? It was opened from a file, it should know that. I just want to persist changes and clear the dirty state. Maybe I'd have the same issues with a regular NSDocument. The other thing (I meant to mention in the original email) is that I can't take advantage of autosave and async file operations, etc. BUT: Do I lose a lot of undo support? I've never tried to implement undo without Core Data. On Apr 8, 2014, at 15:15 , Mike Manzano m...@instantvoodoomagic.com wrote: Depends. Why are you “fighting” Core Data? Mike On Apr 8, 2014, 3:13:12 PM, Rick Mann rm...@latencyzero.com wrote: This may prove to be an unproductive question to pose, so I apologize in advance. I'm generally a big fan of Core Data, but I'm developing a moderately complicated CAD app with libraries and design documents and such, and beginning to wonder if it would be easier to do if I weren't fighting Core Data. I'm wondering what the tradeoffs might be. If I were to dump Core Data, I'd keep the entire object graph in memory all the time, writing it out completely each time. I'd probably write XML, or some other text-based format (as much as I abhor text-based formats) because of the ease in diffing changes and using it with source control. As I write this, I realize that I can't just keep a whole document in memory; the library (which would be a collection of separate files on disk, but presented as a unified collection of content in the UI) could be very large and I'd rather not load in the whole thing. Nevertheless, I think that's doable. I'd have to handle relationships myself, but all the data types become easier to manage (I use a lot of C structs, well, really C++ structs). Thoughts? Thanks! -- Rick - signature.asc, 211 bytes ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/mike%40instantvoodoomagic.com This email sent to m...@instantvoodoomagic.com -- Rick ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/etaffel%40me.com This email sent to etaf...@me.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Opinion: Core Data or roll my own?
On Apr 8, 2014, at 16:41 , edward taffel etaf...@me.com wrote: moving history into your model will better facilitate portability [in case you’re thinking in this direction]. Is that how that works? The history ends up in my model? -- Rick signature.asc Description: Message signed with OpenPGP using GPGMail ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Opinion: Core Data or roll my own?
that’s how i should do it. particularly, if you have complicated selections that me must be undone/redone you’ll find you have excellent control, as well. On Apr 8, 2014, at 7:46 PM, Rick Mann rm...@latencyzero.com wrote: On Apr 8, 2014, at 16:41 , edward taffel etaf...@me.com wrote: moving history into your model will better facilitate portability [in case you’re thinking in this direction]. Is that how that works? The history ends up in my model? -- Rick ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Opinion: Core Data or roll my own?
Hi Rick,
One option is to use SQLite. I've been putting together an open source
BFWQuery library to hopefully simplify the whole thing, by letting you treat
a database query just like an array of dictionaries. It uses FMDB (thanks Gus).
eg: query.resultArray[row][columnName]
Here is an example:
BFWDatabase* database = [[BFWDatabase alloc] initWithPath:[self databasePath]];
BFWQuery* query = [[BFWQuery alloc] initWithDatabase:database
queryString:@select Name, Latitude,
Longitude from Country where Language = ? and Latitude ? order by Name
arguments:@[@English, @30.0]];
for (NSDictionary* rowDict in query.resultArray) {
NSLog(@%@: (%@, %@), rowDict[@Name], rowDict[@Latitude],
rowDict[@Longitude]);
}
Or to just get row 3's value for Name:
query.resultArray[3][@Name];
That's all there is to it.
Behind the scenes, BFWQuery only retrieves rows from the database as requested,
so it doesn't create an in memory array containing all of the results.
Since it's SQL, you can create your own relationships and efficient database
schema, which should perform better than CoreData.
You can also change the data with method calls like:
[database updateTable:@Country
rowDict:@{@Name:@Oz}
whereDict:@{@Name:@Australia}];
See:
https://bitbucket.org/barefeetware/bfwquery
Tom
Tom Brodhurst-Hill
BareFeetWare
--
iPhone/iPad/iPod and Mac software development, specialising in databases
develo...@barefeetware.com
--
Follow us on Twitter: http://twitter.com/barefeetware/
Like us on Facebook: http://www.facebook.com/BareFeetWare
On 9 Apr 2014, at 8:13 am, Rick Mann rm...@latencyzero.com wrote:
I'm generally a big fan of Core Data, but I'm developing a moderately
complicated CAD app with libraries and design documents and such, and
beginning to wonder if it would be easier to do if I weren't fighting Core
Data. I'm wondering what the tradeoffs might be.
If I were to dump Core Data, I'd keep the entire object graph in memory all
the time, writing it out completely each time. I'd probably write XML, or
some other text-based format (as much as I abhor text-based formats) because
of the ease in diffing changes and using it with source control.
As I write this, I realize that I can't just keep a whole document in memory;
the library (which would be a collection of separate files on disk, but
presented as a unified collection of content in the UI) could be very large
and I'd rather not load in the whole thing. Nevertheless, I think that's
doable.
I'd have to handle relationships myself, but all the data types become easier
to manage (I use a lot of C structs, well, really C++ structs).
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Opinion: Core Data or roll my own?
On 9 Apr 2014, at 8:13 am, Rick Mann rm...@latencyzero.com wrote: As I write this, I realize that I can't just keep a whole document in memory; the library (which would be a collection of separate files on disk, but presented as a unified collection of content in the UI) could be very large and I'd rather not load in the whole thing. Nevertheless, I think that's doable. I have no comment regarding Core Data, but just a general comment regarding this remark. This sounds very much like what I do in both our vector apps to present a collection of library items. These run to thousands of items in multiple libraries, organised into sets called categories, presented through a single UI which allows the user to organise them and use them. We don't load the whole collection into memory, though we do have an in-memory representation of that collection which tracks the location of the original file and an image (and other metadata) representing the item. The UI shows that image which is loaded lazily and on a secondary thread, so the UI remains responsive even when scrolling through thousands of items. If the user wants to incorporate a library item into their document, then the real item is loaded at the point of use, and occupies memory from then on. Point is: we've never run into memory or performance issues with this. I guess at some point stuff could well get paged out but we don't do anything to prevent that. In practice, I've rarely noticed delays caused by that occurring, and typically it's been because of another foreground app needing to page its stuff in. In many cases I would imagine that the image we load (a pdf) is actually larger than the real data - but even then it's still not a practical problem. So far we've seen no scalability issues up to the order of tens of thousands of items - how large is your library likely to be? 10,000 different vector objects is actually a pretty large number. Again, in practice the way this is used is that a user often filters that down to a small set of items they need for a project (they can build their own categories, collections and smart sets based on predicates) - an entire collection can be overwhelming - and stuff that's never browsed never even loads the image and metadata, so the reality of the in-memory copy is that it's actually a small subset of what out there on disk almost all of the time. So yes, it's doable - we've done it and it works fine. Unless your needs are significantly larger than this, I wouldn't sweat the memory requirements at this stage. Our scheme doesn't use Core Data. It probably could, but I've never been totally sold on it personally. --Graham ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Opinion: Core Data or roll my own?
On Apr 8, 2014, at 5:31 PM, BareFeetWare list.develo...@barefeetware.com
wrote:
for (NSDictionary* rowDict in query.resultArray) {
NSLog(@%@: (%@, %@), rowDict[@Name], rowDict[@Latitude],
rowDict[@Longitude]);
}
Or to just get row 3's value for Name:
query.resultArray[3][@Name];
Watch out: I have found this degree of abstraction to become a major
performance bottleneck. It results in large numbers of object allocations and
message-sends during query evaluation. Late in development of the first
implementation of Safari RSS in OS X 10.4, I had to go through code like this
and try various nasty tricks to cache and reuse objects, to try to speed it up
enough, because it was too late to redesign the query APIs to be closer to the
metal.
The query API in FMDB itself is more efficient, and I think clearer, although
not perfect. In my current usage I make sure to only use the numeric-indexed
accessors (i.e. get column 2 rather than column “Latitude”) because they’re
much faster.
—Jens
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Opinion: Core Data or roll my own?
On Apr 8, 2014, at 18:09 , Graham Cox graham@bigpond.com wrote: On 9 Apr 2014, at 8:13 am, Rick Mann rm...@latencyzero.com wrote: As I write this, I realize that I can't just keep a whole document in memory; the library (which would be a collection of separate files on disk, but presented as a unified collection of content in the UI) could be very large and I'd rather not load in the whole thing. Nevertheless, I think that's doable. I have no comment regarding Core Data, but just a general comment regarding this remark. This sounds very much like what I do in both our vector apps to present a collection of library items. These run to thousands of items in multiple libraries, organised into sets called categories, presented through a single UI which allows the user to organise them and use them. We don't load the whole collection into memory, though we do have an in-memory representation of that collection which tracks the location of the original file and an image (and other metadata) representing the item. The UI shows that image which is loaded lazily and on a secondary thread, so the UI remains responsive even when scrolling through thousands of items. If the user wants to incorporate a library item into their document, then the real item is loaded at the point of use, and occupies memory from then on. Point is: we've never run into memory or performance issues with this. I guess at some point stuff could well get paged out but we don't do anything to prevent that. In practice, I've rarely noticed delays caused by that occurring, and typically it's been because of another foreground app needing to page its stuff in. In many cases I would imagine that the image we load (a pdf) is actually larger than the real data - but even then it's still not a practical problem. So far we've seen no scalability issues up to the order of tens of thousands of items - how large is your library likely to be? 10,000 different vector objects is actually a pretty large number. Again, in practice the way this is used is that a user often filters that down to a small set of items they need for a project (they can build their own categories, collections and smart sets based on predicates) - an entire collection can be overwhelming - and stuff that's never browsed never even loads the image and metadata, so the reality of the in-memory copy is that it's actually a small subset of what out there on disk almost all of the time. So yes, it's doable - we've done it and it works fine. Unless your needs are significantly larger than this, I wouldn't sweat the memory requirements at this stage. Our scheme doesn't use Core Data. It probably could, but I've never been totally sold on it personally. Thanks for that data point, Graham. My app is very similar in this regard to yours, and that's exactly how I was thinking of treating it. On Apr 8, 2014, at 17:31 , BareFeetWare list.develo...@barefeetware.com wrote: One option is to use SQLite. I've been putting together an open source BFWQuery library to hopefully simplify the whole thing, by letting you treat a database query just like an array of dictionaries. It uses FMDB (thanks Gus). Well, if I were to do this, one of the reasons would be to create a text representation that could be easily diffed. I took a look at Core Data's XML format, and while necessarily verbose, it would work pretty well, until the schema changed. -- Rick signature.asc Description: Message signed with OpenPGP using GPGMail ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
