Re: Why is it wrong to have relationships without an inverse in Core Data?
Re: Why is it wrong to have relationships without an inverse in Core Data?
- Subject: Re: Why is it wrong to have relationships without an inverse in Core Data?
- From: Ian Joyner <email@hidden>
- Date: Mon, 24 Jun 2013 17:07:06 +1000
The other reason I can think of for not classifying CoreData as a database is that CD is only meant for one application (at a time anyway), whereas specific databases (as in DB management systems DBMS) are meant to be shared on a massive scale.
Another interesting point from Codd is that he very much envisaged databases to be used by end users and not (just) by programmers. This was before Xerox PARC and Apple, and this is where SQL is a 'psychological' failure.
On 24 Jun 2013, at 11:23, Ian Joyner <email@hidden> wrote:
> On 23 Jun 2013, at 13:32, "Reaves, Timothy" <email@hidden> wrote:
>
>> What the docs state that is meaningless (although inaccurate); the
>> Objectice-C manual could very easily state that Objective-C is not a
>> programing language; it is. CoreData is a database.
>
> OK, what the Apple doc http://developer.apple.com/library/mac/#documentation/cocoa/Conceptual/CoreData/Articles/cdTechnologyOverview.html#//apple_ref/doc/uid/TP40009296-SW1 says:
>
> "Core Data is not a relational database or a relational database management system (RDBMS).
>
> "Core Data provides an infrastructure for change management and for saving objects to and retrieving them from storage. It can use SQLite as one of its persistent store types. It is not, though, in and of itself a database"
>
> I agree with you in the general sense, but I think the docs are speaking in the more specific sense. CoreData is really the middleman which can interface to a number of data stores. To think of a database as a data store is also misleading because the relational model is very high-level and very abstract and about as far away from data store as you could get.
>
> CoreData is more a modelling system (I could say data model... but it's not that either). Thus programmers should be abstracted away from the physical storage medium (which I think is a point you are making).
>
> However, CD does rather look like the entity-relationship model, which is fundamentally broken by distinguishing between entities and relationships and lacks precision and formality (correctness and flexibility) which the relational model has.
>
> So in one sense you are right it is a database, but I'd say more a definer of data models and these happen to get stored somewhere in a database. But CD is not that database itself - it is the glue between the DB (or in-memory store) and an application program.
>
>> A database need never
>> write anything to a file. There are - in fact - several examples, of all
>> manor, of in-memeory data bases that never bother to persist to a file. As
>> the documentation points out, there are five(?)(XML, plist, SQLite, iCould,
>> in-memory) supported backing stores. Four will cause a file to be created,
>> and one will not.
>>
>> Yes, it's fully possible for CoreData to be broken into two components; one
>> that manages object graphs, and one that manages persisting them. But
>> until that time, CoreData is a framework/library/module with the intention
>> of causing data to be stored, even if only in memory. That, by definition,
>> makes it a database, and when at least one particular backing stores is
>> used, it also makes it an ORM. That it can do other things is irrelevant.
>>
>> Now, enough with the philosophy! :-D
>>
>>
>>
>>
>>
>> On Sat, Jun 22, 2013 at 4:19 PM, Luther Baker <email@hidden> wrote:
>>
>>> ... yes, and if you are going to be pedantic, please be somehow consistent
>>> with the docs:
>>>
>>>> Core Data provides an infrastructure for change management and for
>>> saving objects to and retrieving them from storage. It can use SQLite as
>>> one of its persistent store types. *It is not, though, in and of itself a
>>> database.* (To emphasize this point: you could for example use just an
>>> in-memory store in your application. You could use Core Data for change
>>> tracking and management, but never actually save any data in a file.)
>>>
>>>
>>> http://developer.apple.com/library/mac/#documentation/cocoa/Conceptual/CoreData/Articles/cdTechnologyOverview.html#//apple_ref/doc/uid/TP40009296-SW1
>>>
>>>
>>>
>>>
>>> On Sat, Jun 22, 2013 at 1:26 PM, Timothy Reaves <
>>> email@hidden> wrote:
>>>
>>>> Yes, CoreData is a database, and it does do ORM. It's not just an ORM,
>>>> and it's not an RDBMS.
>>>>
>>>> If it wasn't a database, it couldn't store data; that is the definition
>>>> of a database. A database is not something that has row, columns, etc; it's
>>>> something that stores data in an unspecified manor. Yes, and ASCII file
>>>> can be a database, as many, many are on the mainframe. You seem to be
>>>> confused as to what a database is.
>>>>
>>>> If CoreData didn't do ORM, it couldn't persist objects into a SQL
>>>> database, which it does with SQLite. It is not 'just' an ORM, and the ORM
>>>> features may be optional, but they are still there.
>>>>
>>>> If you are going to be pedantic, be accurate in your pedanticism.
>>>>
>>>>
>>>>
>>>>
>>>> On Jun 22, 2013, at 10:37 AM, Kyle Sluder <email@hidden> wrote:
>>>>
>>>>> On Jun 22, 2013, at 12:55 AM, Rick Mann <email@hidden> wrote:
>>>>>
>>>>>>
>>>>>> On Jun 22, 2013, at 00:50 , Keith J. Schultz <email@hidden>
>>>> wrote:
>>>>>>
>>>>>>> Core data helps in setting up the database, but deleting is another
>>>> matter.
>>>>>>> You should do that manually for consistency. Core Data has no
>>>> knowledge of the
>>>>>>> semantics of your database. so use prepareToDelete.
>>>>>
>>>>> I'm sorry, but what?
>>>>>
>>>>> 1. Core Data is NOT a database. It is NOT an ORM. Core Data is a model
>>>> object persistence and management framework. It just so happens that it can
>>>> use a SQLite database as a storage backend. It can also use XML.
>>>>>
>>>>> 2. Core Data very well does understand the semantics of your data
>>>> model. That's what the data model _is_. Core Data is not somehow crippled
>>>> in understanding deletions. It even has deletion propagation and validation.
>>>>>
>>>>> Seriously, if you're gonna knock on Core Data (for which there is
>>>> PLENTY to knock on), at least come up with valid criticisms.
>>>>>
>>>>> --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
>
>
> _______________________________________________
>
> 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