Actually, there is no reason CoreData can't be used in this manner, but there are things that will have to be dealt with outside of CoreData. How do you deal with two people making changes to the same record concurrently as an example ( this is not an issue exclusive to CoreData, but multi-user design ). How do you deal with scalability issues when you have data sets that start creeping into the 5 or 10gb ranges? But the big one that I see with CoreData powered web apps is something that boils down to a design pattern.
In the easiest deployment model, you are looking at using CGI, which means that your server app runs in very short lifecycles and when multiple requests come in you get multiple instances of the same CGI application running and accessing the same CoreData data files at the same time. This is an access model that can be problematical. You can work around it, and honestly, Cocoa makes that fairly easy to do, but it is something that has to be dealt with. The net result is this (IMO, and it is just that Opinion): CoreData is incredibly powerful and a truly fantastic tool well designed and well implemented to meet it's primary goal of serving as a robust data store for Cocoa applications. Though it has many features that enable it to play against larger scale RDBMS platforms for small implementations, it is not a full on RDBMS system. When you start talking server class applications with multi-user access and large datasets, it is time to look beyond the CoreData world. I generally advocate starting in the RDBMS world if a project has any potential to scale beyond CoreData simply because there is not a good migration path from CoreData to something larger. I find this frustrating, because EO was truly revolutionary and even today competes well against similar projects, and it hasn't been actively updated for at LEAST 5 years. Dru On Oct 17, 2013, at 8:05 AM, Brad Gibbs <bradgi...@mac.com> wrote: > I don’t have a degree in comp sci and, while I program in Cocoa and Rails on > a daily basis, it’s not my primary job function, so, I’m sure I don’t fully > appreciate a statement like “Core Data has no semantics for asynchronous, > failed, or cancelable operations.” I’m not in any way trying to pick a fight > with anyone. I want to build an app to help run my small business. I want > to provide a way for my employees, who are scattered across the country, to > be able to share data to make our business more efficient and more scaleable. > > A pure Rails app served through a browser seems to be a well-accepted > multi-user database solution, allowing thousands to interact with the same > set of data simultaneously. It also seems fairly common to use Rails as a > back-end for native iOS and OS X apps (hence, the popularity of > AFNetworking). The problem seems to be injecting Core Data into that mix. > Is that a fair summary? > > IMO, Core Data makes creating and updating the UI much more straight-forward. > And, it makes view controllers thinner. It’s a good fit for the rest of > Cocoa. It may be because the only tool I have is a hammer, but fighting to > bring Core Data into the picture seems like a worthwhile endeavor. > > I believe there are two options to use CD locally with a Rails API backend: > > 1. Manual. Core Data attributes are serialized into JSON objects and sent > to the server. JSON comes back and is manually parsed to update affected > objects. My understanding is that typically, a MOC on the main thread is > backed by a second MOC on a background thread. The backing MOC handles > requests to and responses from the server asynchronously and changes bubble > up from a managedObjectContextDidSave: notification. Are there serious > concerns about this method? Or, is it just the use of NSIncrementalStore > that’s at issue? > > 2. AF/NSIncrementalStore. CD itself may not be asynchronous, but the > network calls to the Rails API are asynchronous and cancelable, and, we get > notified if they fail. Again, I’m no expert here, but it seems that the > introduction of NSURLSession and background fetching along with real time web > apps (via something like Rocket.io) improve the situation. If an > NSURLSessionDataTask fails, notify the user and rollback the local store. I > know there was an issue with the synchronous nature of CD and temporary vs. > permanent managedObjectIDs, but AFIncrementalStore seems to have solved this. > > I’m looking forward to seeing what Matt Thompson does with AFIncrementalStore > once the dust has settled on AFNetworking 2.0. > > On Oct 16, 2013, at 7:46 PM, Kyle Sluder <k...@ksluder.com> wrote: > >> On Wed, Oct 16, 2013, at 04:26 PM, Alex Kac wrote: >>> Can’t you use NSIncrementalStore to talk with REST services as a backend >>> for Core Data? I remember seeing some articles on this. >> >> You can, and many people have tried, but it inevitably fails because >> Core Data has no semantics for asynchonous, failed, or cancellable >> operations. >> >> https://twitter.com/JimRoepcke/status/301893533860757505 >> >> Don't use NSIncrementalStore for remote operations until Apple fixes the >> API. >> >> --Kyle Sluder >> >> _______________________________________________ >> >> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) >> >> 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: >> https://lists.apple.com/mailman/options/cocoa-dev/bradgibbs%40mac.com >> >> This email sent to bradgi...@mac.com > > > _______________________________________________ > > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) > > 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: > https://lists.apple.com/mailman/options/cocoa-dev/dru%40druware.com > > This email sent to d...@druware.com _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
