• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: HELP! - Database questions
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: HELP! - Database questions


  • Subject: Re: HELP! - Database questions
  • From: Chris Hanson <email@hidden>
  • Date: Fri, 7 Mar 2008 12:54:02 -0800

On Mar 7, 2008, at 11:40 AM, David Dunham wrote:

I've used SQLite, it's great since you can embed it for free. However, I don't think it really allows for use as a server.

And since Core Data sits atop SQLite, it's probably not an option either. (I don't think it *can* let you use SQL directly, since the whole idea is to abstract the underlying data store.)

Core Data can use a SQLite-based persistent store, but it's a persistent (ha) myth that Core Data "sits atop" or is "built on" SQLite. Core Data is an object graph management and persistence API, it's not a SQLite wrapper.


Furthermore, when hosted on an appropriate file server -- and when all clients access the file through the same mechanism -- a SQLite database located in a shared filesystem can be safely accessed and manipulated by multiple users. Keep in mind, though, that this isn't a "SQLite server," it's a file server with a SQLite database file on it, so it has the scaling issues you might expect from a shared filesystem. It should not have any data-integrity issues, however, so long as all clients access the file through the same file-sharing mechanism. (Don't mix & match SMB and NFS, for example.)

Core Data even has API for handling cases where there are multiple clients accessing the same SQLite-based persistent store, whether they are threads in the same process on a single machine, or processes on different systems accessing a database file on a shared filesystem. Specifically, the NSManagedObjectContext staleness interval is used to determine when cached data should be aged out, and the NSManagedObjectContext merge policies determine how data that has changed in the database and has come back from a fetch should affect data on the client.

If anyone wants to discuss this further, I strongly suggest we take it to cocoa-dev. And if you have needs that aren't currently covered by Core Data, or that could be covered better in different ways, please file a bug in Apple's bug reporter at <http://bugreport.apple.com/> detailing what you'd like to see.

  -- Chris

_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden


References: 
 >HELP! - Database questions (From: Jeff Brown <email@hidden>)
 >Re: HELP! - Database questions (From: David Dunham <email@hidden>)

  • Prev by Date: Re: Question about how to debug iPhone application on the iPhone device
  • Next by Date: Re: Installing Xcode 3.1
  • Previous by thread: Re: HELP! - Database questions
  • Next by thread: Re: HELP! - Database questions
  • Index(es):
    • Date
    • Thread