Re: nsarraycontroller, bindings and big databases
Re: nsarraycontroller, bindings and big databases
- Subject: Re: nsarraycontroller, bindings and big databases
- From: "Joris Mans" <email@hidden>
- Date: Wed, 15 Feb 2006 13:35:45 +0100
Wouldnt it be possible to just fill the NSArray with NSMutableDictionary subclasses ( or another class which is KVC compliant which i make myself) and at the moment the app asks for the data, query the database and get the values? In able for this to work i need to be sure that the column objects only ask the values of the visual items in the table.
Joris
----- Original Message -----
From: Jack Nutting
To: Joris Mans
Cc: Aurélien Hugelé ; Cocoa-dev
Sent: Wednesday, February 15, 2006 1:00 PM
Subject: Re: nsarraycontroller, bindings and big databases
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