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: Alexander Lamb <email@hidden>
- Date: Fri, 13 Oct 2006 15:32:52 +0200
Thanks a lot for the info!
You could imagine synchronizing the data directly at the database
level if your local store was SQLite. Indeed, you could SQL the data
out into temporary files then into SQLite using SQL. Of course your
CoreData app would then be desynchronized and you would have to
reload after the transfert.
What I see here is that you don't have a notification issue (if the
server changes, clients are not notified).
Alex
--
Alexander Lamb
email@hidden
On Oct 12, 2006, at 6:07 PM, Andrew Satori wrote:
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