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: Fri, 13 Oct 2006 09:44:13 -0400
For this application, it's not needed. It's rare for two users to
have the same records open at once.
On Oct 13, 2006, at 9:32 AM, Alexander Lamb wrote:
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