• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Opinion: Core Data or roll my own?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Opinion: Core Data or roll my own?


  • Subject: Re: Opinion: Core Data or roll my own?
  • From: BareFeetWare <email@hidden>
  • Date: Fri, 16 May 2014 18:38:29 +1000

On Apr 8, 2014, at 5:31 PM, BareFeetWare <email@hidden> 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 <email@hidden> 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
email@hidden
--
Follow us on Twitter: http://twitter.com/barefeetware/
Like us on Facebook: http://www.facebook.com/BareFeetWare
_______________________________________________

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


  • Prev by Date: Re: where to put persistent storage for command-line app
  • Next by Date: Re: debugging unrecognized selector
  • Previous by thread: Re: debugging unrecognized selector
  • Next by thread: setUsesFontPanel:NO for a given NSColorWell only
  • Index(es):
    • Date
    • Thread