Using CoreData as disconnected cache (Populating CoreData programmatically)

  • Alright, so I've been working on a project that needs to deal with
    disconnected updates and synchronization.

    What I've got is a large server based database with potentially
    hundreds of concurrent users.  That side is done, and is relatively
    easy.

    Now I have a project to modify one of the applications to be able to
    cache a copy of relevant records to be disconnected and taken offsite
    to a location where remote access of any form will be 'iffy' at
    best.  I've got a theory, but I'm having trouble implementing it.

    What I would like to do is have the 'client' contact the server and
    create a cache of the server data in CoreData, then use CoreData for
    the application, then upon return sync the CoreData files back to the
    server.  I see this as the 'application', the import (with it's
    select criteria based upon files to be used that day), and return to
    the office sync, which is to be non-desctructive, and additive only.

    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.
  • 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/CoreDataUtilityTu
    torial/
    > 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
  • 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
    >
  • 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
    <alamb...>

    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      (<Cocoa-dev...>)
    > Help/Unsubscribe/Update your Subscription:
    > http://lists.apple.com/mailman/options/cocoa-dev/<alamb...>
    >
    > This email sent to <alamb...>
  • 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
    > <alamb...>
    >
    >
    >
    > 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      (<Cocoa-dev...>)
    >> Help/Unsubscribe/Update your Subscription:
    >> http://lists.apple.com/mailman/options/cocoa-dev/<alamb...>
    >>
    >> This email sent to <alamb...>
    >
  • 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
    <alamb...>

    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
    >> <alamb...>
    >>
    >>
    >>
    >> 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      (<Cocoa-dev...>)
    >>> Help/Unsubscribe/Update your Subscription:
    >>> http://lists.apple.com/mailman/options/cocoa-dev/<alamb...>
    >>>
    >>> This email sent to <alamb...>
    >>
    >
  • 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
    > <alamb...>
    >
    >
    >
    > 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
    >>> <alamb...>
    >>>
    >>>
    >>>
    >>> 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      (<Cocoa-dev...>)
    >>>> Help/Unsubscribe/Update your Subscription:
    >>>> http://lists.apple.com/mailman/options/cocoa-dev/<alamb...>
    >>>>
    >>>> This email sent to <alamb...>
    >>>
    >>
    >
previous month october 2006 next month
MTWTFSS
            1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31          
Go to today