Re: Core Data with ODBC databases?
Re: Core Data with ODBC databases?
- Subject: Re: Core Data with ODBC databases?
- From: Brad Gibbs <email@hidden>
- Date: Thu, 17 Oct 2013 08:05:25 -0400
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 <email@hidden> 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 (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
_______________________________________________
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