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: "Reaves, Timothy" <email@hidden>
- Date: Sat, 22 Jun 2013 23:32:19 -0400
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. 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