Re: nsarraycontroller, bindings and big databases
Re: nsarraycontroller, bindings and big databases
- Subject: Re: nsarraycontroller, bindings and big databases
- From: Jack Nutting <email@hidden>
- Date: Wed, 15 Feb 2006 13:00:29 +0100
On 2/15/06, Joris Mans <email@hidden> wrote:
>
> What do you mean by "firing faults"? (I am no expert on core data because
> i
> cannot use it for reasons cited below).
> I think you didnt understand the question completely.
> The amount of data in my tables is just too big to load in memory at once
> and I cannot use core data because i am interfacing with a PostgreSQL
> database on a server. Just think of the database containing too much data
> to
> fit in a reasonable amount of memory. How can we handle this problem with
> bindings?
NSArrayController will only work with a "full" array of objects. The way
this works within CoreData is that the NSArrayController is populated with a
bunch of fault objects. A fault can be thought of as a proxy for the actual
data-bearing object. To "fire a fault" means "call a method that needs to
access the actual data behind the fault", which triggers a set of actions
that grab the actual data from the data store, and replace the fault with
the real data-bearing object. This is done more-or-less transparently and
automatically by CoreData, so that at the application level, you seldom need
to worry about it, and your application can act as if all saved data is
always available in memory.
So that's how it works in CoreData. In your case, where you've got a data
store that doesn't work directly with CoreData, you've got a couple of
options. You could write a custom data store that interfaces with
PostgreSQL, but that's probably a pretty big job. An easier solution may be
to forego bindings, and instead implement the NSTableView datasource methods
in your controller object. That's the way NSTableView was used for a decade
before bindings came along, and it's pretty easy to set up. NSTableView
uses "lazy loading" to only ask for the table data that's currently being
displayed, so your app won't try reading the entire database at once.
Assuming you've got a reliable method for grabbing the rows you needs from
PostgreSQL ("give me the Nth row"), this may be enough.
--
// jack
// http://www.nuthole.com
_______________________________________________
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