Re: Sync Services for Multi-machine Core Data App?
Re: Sync Services for Multi-machine Core Data App?
- Subject: Re: Sync Services for Multi-machine Core Data App?
- From: Nick Zitzmann <email@hidden>
- Date: Mon, 07 Mar 2011 00:42:14 -0700
On Mar 6, 2011, at 11:23 PM, Steve Steinitz wrote:
> Hi,
>
> Our Core Data point-of-sale app currently shares a sqlite database on an NAS, each machine periodically fetching fresh data and, of course, saving. It works well and fast but is vulnerable to:
>
> network failure,
> Apple preventing it (as evidenced briefly in 10.6.2),
> sqlite multi-user quirks,
> afp quirks
> etc...
>
> So, I've begun playing with Sync Services: each machine will have its own local database store and will do peer and truth Sync Services syncs.
>
> My question: is that a good idea?
No.
> I saw recent wild speculation on Apple's Sync Services mailing list that Apple may quietly drop Sync Services in Mac OS X Lion.
Do you believe everything that you read? Apple dropped calendar syncing with MobileMe recently, but MobileMe is more than just syncing contacts and calendars (though it did anger the developers of some calendaring applications).
> Also, I'm not clear whether Sync Services was meant to sync millions of records of a complex schema.
No, it does not. Sync Services scales poorly and works best with up to a few thousand small records. Creating multi-megabyte records, or millions of small records, will cause syncing to take a looooong time (especially if you have identity properties set), and probably take several gigabytes of RAM just to run a session. We make a sync client, and before we built it for X86-64, we had several users crash it by attempting to sync too much data.
> Note that, in the past, many have cheerfully suggested that I just pop out and roll my own bullet-proof client-server architecture. I haven't the desire, heart, nor budget for that garden path. Nor am I convinced its a good idea. Feel free to address that but I'm more interested in:
>
> So, Sync Services?
If you need a multi-machine database-driven application, then you should use ODBC, not CoreData, with either MySQL or PostgreSQL or some commercial engine on the back end.
Nick Zitzmann
<http://www.chronosnet.com/>
_______________________________________________
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