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 11:19:46 -0400
Flavio responded while I was editing, so, this is just re-iterating some of his points.
I’m not sure whether you (Dru) were responding to my post, or just responding to the thread, in general.
Using a Rails API-based backend with a PostgreSQL database means that Core Data doesn’t have to scale at all. Postgres and the Rails API need to be scaleable, but, that’s exactly what they’re designed for. Core Data is still a local cache being used by a single user, but instead of persisting to the local disk, it’s persisting to the Postgres server. There are issues there revolving around cache policies, etc., but, I think NSURLSessiion and background fetching will ease a lot of that pain.
As for two people making changes to a record simultaneously, it would be handled in the same way a Rails web app would handle it. Rails and Postgres have been designed for this use case.
As for large data sets, that’s part of the beauty of the NSIncrementalStore approach. In its purest form, the full data set wouldn’t exist on any one user’s device. Instead, NSIncrementalStore would fetch the data requested by the user from the server, as needed, by firing faults. If NSIncrementalStore worked as advertised, there would be no need to persist the entire data set to a user’s device.
Additionally, mobile apps would probably be written for specific uses. Maybe the entire company’s data set is 10GB, but the sales team really only needs access to 1GB of that information and perhaps even less for a mobile app while they’re in the field.
I honestly don’t know whether Apple has provided a “complete enough” stub-out with NSIncrementalStore. Mattt and Heroku seem to think so. It seems like there are still some hurdles to overcome with the current implementation of AFIncrementalStore. I’m assuming that Mattt is laying the groundwork in AFNetworking 2.0 first, and will then come back to AFIS, update it for AFN 2.0 and work out some of the remaining kinks.
I think there’s a huge need for something like this in SMB. iCloud + Core Data doesn’t serve the purpose, whether it works or not. It took Apple 2+ years to provide any real documentation for NSIS and there’s no sample code from Apple. Maybe that’s because it doesn’t / can’t work, or, maybe it’s just not high enough on their list of priorities.
Has anyone seen a non-trivial example of NSIS or AFIS with multiple entities, relationships and a complete CRUD implementation? Not the sample code that’s packaged with AFIS, but something more substantial?
On Oct 17, 2013, at 8:23 AM, Andrew Satori <email@hidden> wrote:
> 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 <email@hidden> 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 <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
>
>
_______________________________________________
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