Re: Using CoreData as disconnected cache (Populating CoreData programmatically)
Re: Using CoreData as disconnected cache (Populating CoreData programmatically)
- Subject: Re: Using CoreData as disconnected cache (Populating CoreData programmatically)
- From: Andrew Satori <email@hidden>
- Date: Thu, 12 Oct 2006 12:07:51 -0400
Having had to do this on a few different occasions, I've elected to
this using a dual key lock.
On the local, I maintain a 'changelog' that documents the entity and
attribute that gets changed (in this case it's primarily additive
information in the way of current statistics and notes), and a tag
for 'sync date/timestamp' for the local dataset. On the server all
records have a last modified timestamp and who field on each record.
When a sync is performed, the local dataset performs add's without
check, but any edit's are verified against the timestamp. if the
server timestamp is newer than the sync date, that record is flagged
for contention and requires human intervention to confirm the
update. There are exceptions, fields where the returning recordset
is considered the definitive value, and no conflict will be raised,
but that's a by design thing.
From Server to client for this instance is very straightforward.
The mobile dataset is being taken to meetings, and those meetings are
maintained in a server side calendar table. So, when the download is
requested, it's is done by date range. The pull looks up the list of
records needed and then pulls down a replica of the records and all
associated data for each one. This is a destructive process, in that
we blow away the old file as the first thing and then pull a fresh
set of data every time. It means more data over the wire, but less
risk for 'old data' contamination.
No, the Server is MS SQL Server or PostgreSQL depending upon the
installation. Pulling the data will be an ODBC Client on the Mac
that runs SQL against the ODBC DataSource and then converts it into
the CoreData entities locally. Using an Application Server, using
SOAP or XMLRPC in this instance makes it easier to run over http(s)
however, with the inflation of the data stream size inherent in those
methodologies, the resulting bandwidth requirements make a 5-10
minute process a 10-30 minute process, even when on local ethernet.
Doing this over a 678k DSL line would be impractical at best.
We considered just installing PostgreSQL locally and doing the
transfers that way, but the administration issues really don't appeal
there.
On Oct 12, 2006, at 11:31 AM, Alexander Lamb wrote:
Hello,
What you are trying to do is interesting... since I am looking into
this as well I was wondering how you were going to handle updates.
1) From client to server.
Since you first write to your local data store (as if the programme
is actually single user), it means somewhere you will need to tell
the app "push updates to the server". You can't send the complete
local database each time. Also, since it will (probably) be
asynchronous from the user data entry, how will you handle
collisions on the server. Who is correct? The last one saving?
2) From server to client.
From what I understand, the client basically says "give me a subset
of the data". How does he specify the subset? Depending on the
subset, you might pull out most of the database (be aware of deep
copying objects).
Also, even if you get your subset, you then are disconnected. How
do you notify your client that some data he copied has changed on
the server?
Finally, is your server CoreData based or is it a more traditional
database server and you will be running sql directly to get the
data and update it (are you going through an application server or
directly to the data)?
Thanks,
Alex
--
Alexander Lamb
email@hidden
On Oct 11, 2006, at 8:18 PM, Andrew Satori wrote:
You know, sometimes all it takes is a prod :-). Thanks Chris,
that's exactly what I needed. A quick test and it works like a
charm.
Andy
On Oct 11, 2006, at 2:05 PM, Chris Hanson wrote:
On Oct 11, 2006, at 9:22 AM, Andrew Satori wrote:
So in order to test this, I've started with the import, and I'm
already stuck. I cannot seem to find any examples of how to add
data to a coredata model programmatically. I can find CoreData
with bindings examples everywhere, but nothing about doing this
in code, and I'm looking for some direction to look for more
information on the subject.
What documentation have you looked at? The Low-Level Core Data
Tutorial <http://developer.apple.com/documentation/Cocoa/
Conceptual/CoreDataUtilityTutorial/> and the Core Data reference
documentation should tell you what you need to know about working
with Core Data persistent stores programmatically.
Also — and I know I mention this in practically every other
message on the subject — it's important to use correct
terminology to think about the problem as it will make both
finding answers to your questions and designing your application
a lot easier. I'm specifically referring to your "add data to a
coredata model" statement. You actually insert managed objects
into a managed object context that is connected to a persistent
store coordinator with any number of persistent stores added to
it, and ask the managed object context to save the changes you've
made to your object graph.
The terminology in the preceding paragraph directly mirrors the
names of the classes you'll need to deal with and the operations
you'll need to ask them to perform. Sometimes developers
familiar with Core Data will speak in shorthand, e.g. "context"
instead of "managed object context" and "coordinator" or "store"
instead of "persistent store coordinator" or "persistent store"
but by and large if you stick to the terms used by the classes,
the path to the solution can sometimes practically chart itself.
-- Chris
_______________________________________________
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
_______________________________________________
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