That’s more a means than an end. The idea is to abstract managed, scalable desktop data storage and access for Cocoa application. It just works out that SQLite fits in well here. Core Data is not designed as a general front end to a RDBMS, it just solves many of the same problems.

I mean, people were talking about mapping tables in MySQL to CoreData objects and how the Outer Joins were not supported.

When you’re holding a hammer, everything look like a nail. :)

The idea with Core Data is to shift your attention away from the query (the how) and towards objects (the what).

When somebody asks how to do ‘X’ or ‘Y’ in bindings/Core Data, the first response is often “what are you trying to accomplish?” If something seems too difficult in Cocoa/Core Data, it’s often the case that there’s an easier strategy that has the same net result.

I mean, people were talking about mapping tables in MySQL to CoreData objects and how the Outer Joins were not supported. It sure sounded a lot like ORM.

For simple things I can see how this would be useful, but then again, for simple things anything is useful. Most of the problems appear when trying to scale.

I’m really surprised to hear this.

I’m surprised that people are still looking for the holy grail of data-driven applications: create them without programming.

That’s not the idea behind Core Data at all. The idea is to not write code for things that can be generalized.