Re: Core Data with ODBC databases?
Re: Core Data with ODBC databases?
- Subject: Re: Core Data with ODBC databases?
- From: Flavio Donadio <email@hidden>
- Date: Wed, 16 Oct 2013 13:47:06 -0300
On 16/10/2013, at 13:11, Andrew Satori <email@hidden> wrote:
> At the root of things, what I think we are really discussing is a model not about CoreData, but one about CoreWebServices. Could we build a framework that let's you model your data in a modeler, and it publishes the model to a RESTful web service via JSON? Absolutely, but ODBC probably isn't the right vehicle. In this instance, you could in fact even do it in CoreData (I wouldn't but you certainly could).
That's what I am talking about!
For sure, ODBC is not the answer here, nor direct client access to the database, as we need something to manage locking and concurrency, as you said -- unless the RDBMS can do that. Is there such a beast?
The reason we look to CoreData as a Holy Grail kind of thing is that it makes it just too easy (before it gets complicated, which is a real issue): just model the data, write some custom accessors (if needed) and validators (if the standard ones don't suffice) and bind the interface elements.
So, it doesn't have to be CoreData, but it has to be something as simple as that. Well, not *that* simple -- as enterprise applications are not as simple as, let's say, a recipe management app or even Delicious Library!
I studied two options in the past:
1. Use CoreData for the client and server. The server would be a command-line utility and would exchange data with the client through XML or JSON (implementing a RESTful web service). This way, the model (and some other code) can be shared between the two components, but SQLite is not so robust for multi-user applications;
2. Use something else for the server (I use Project WOnder, which is, simply put, a *huge* collection of enhancements to WebObjects) to implement a RESTful web service, and AFIncrementalStore (a CoreData store which persists data through a web service) on the client. This makes it easy to use powerful RDBMSs, but you have to manage the two "identical" data models.
I stuck with option 2. It's not my dream toolset, but works well.
Cheers,
Flavio
_______________________________________________
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