• 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: Cocoa Newbie & MySQL
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Cocoa Newbie & MySQL


  • Subject: Re: Cocoa Newbie & MySQL
  • From: Joshua Tidsbury <email@hidden>
  • Date: Wed, 28 Apr 2010 13:57:09 -0400

Thank you all for your helpful replies so far - greatly appreciated!

To add some clarity: The application is essentially a server side app that will manage various background file moving/archiving processes and store metadata about the files in a database.  The heavy lifting in terms of file analysis and moving the materials around and storing the metadata in the database will entirely be done by a Cocoa application running on a server. I want the end users to be able to browse/search the metadata from a web based application for the sake of cross-platform compatibility, and ultimately their actions within the web app will trigger jobs within the server app. I was planning on some sort of SOAP interface in the Cocoa app to accept commands from the web application to trigger the jobs.

I haven't yet decided on the framework for the web app (often use Rails for standalone web apps, may use PHP), but just don't want to box myself into a corner by a bad decision early on.  Obviously, the notion of being able to use Core Data/SQLite on the server is highly appealing due to the clean integration with the Cocoa app.  But would I be foolish to assume that performance (at most, 50 web users at a time) would be fine with the web app also querying that same database?

Thanks again,
Josh


On 2010-04-28, at 1:39 PM, Bill Bumgarner wrote:

>
> On Apr 28, 2010, at 10:35 AM, Jens Alfke wrote:
>
> > SQLite works fine with multiple clients — it uses file locking to support transactions and ACID properties. I’ve used it that way myself. It just doesn’t scale as well as a full server-based system, because doing locking via the filesystem is slower than doing it in memory. But this is unlikely to affect you unless you’re doing really heavy-duty stuff. On the plus side, sqlite is already installed in the OS and is a zillion times easier to maintain than mysql (since the database is just a file, with no special access/permissions issues.)
>
> Only if the underlying filesystem absolutely positively gets locking right.   Fine for HFS+, not so fine for various network filesystems and/or other operating systems.   Even in the network filesystem case where locking is correct, it may be horrendously inefficient.   Coherency can be an issue, too, depending on filesystem.
>
> I.e. avoid network filesystems with SQLite & multiple clients.  Down that path lies pain.
>
> Related, don't use SQLite modifications as an IPC mechanism.  If you need app A to detect changes to the database from app B, use some other notification mechanism beyond watching the database file for changes.
>
> b.bum
>
>

_______________________________________________

Cocoa-dev mailing list (email@hidden)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden

  • Follow-Ups:
    • Re: Cocoa Newbie & MySQL
      • From: Jens Alfke <email@hidden>
References: 
 >Cocoa Newbie & MySQL (From: Joshua Tidsbury <email@hidden>)
 >Re: Cocoa Newbie & MySQL (From: Jens Alfke <email@hidden>)
 >Re: Cocoa Newbie & MySQL (From: Bill Bumgarner <email@hidden>)

  • Prev by Date: Re: NSKeyedArchiver and NSPoints
  • Next by Date: Re: Finder file label from cocoa?
  • Previous by thread: Re: Cocoa Newbie & MySQL
  • Next by thread: Re: Cocoa Newbie & MySQL
  • Index(es):
    • Date
    • Thread