• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Extension of CoreData to third party databases.
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Extension of CoreData to third party databases.


  • Subject: Re: Extension of CoreData to third party databases.
  • From: Scott Ellsworth <email@hidden>
  • Date: Tue, 29 Nov 2005 16:21:31 -0800

Warning: minor thread hijack

On Nov 29, 2005, at 1:18 PM, Bill Bumgarner wrote:

On Nov 29, 2005, at 12:37 PM, Ruslan Zasukhin wrote:It is more interesting discuss technical aspects of Core Data model.

What have excite me, is that I have read that CoreData is designed without
thinking about some particular db, and wow, without thinking only about
relational model.

That is correct. Core Data is a storage agnostic solution for managing object graphs in Cocoa applications (GUI or non-GUI). The persistency side is designed to be opaque beyond basic file format decisions (XML -- fat and parseable, binary -- relative fast and atomic, SQL -- scalable and non-atomic).


The real power of Core Data is in the change management, from KVC/ KVO through to validation and tight integration with Cocoa Bindings and Controllers.

and

The persistent store API is not public at this time.

I would like to see the persistent store API become public. (I accept that this will not happen until Leopard, most like, but I would like to see it then.)


As part of that, I would like some of the relational goodies from EOF to move into Core Data, so I could hook up to a MySql or Oracle instance used by many people. The change management, validation, and integration features are really keen, and have helped me in a number of standalone apps, but some sprinkling of EOF dust on it (a mysql adapter, an oracle adapter, and some kind of multi user synchronizing, even if very primitive.) would make my life better, and would let me use Cocoa in places where I must use web apps, .NET, or Java right now.

Let me be clear - this is not Core Data's current mission, but I think it is not far from that mission. I do not want Core Data to become WO - my goal is to write a standalone application that I can use with a local or a remote store. A remote store might already exist, and might have multiple users.

To give context, the vast majority of my apps work against already existing data stores, which might have existing .NET or Java clients. Core Data, if it could talk to those stores, would let me write editors, validators, dashboards, and other one-off tools, possibly for just one or two people at a biotech company. Writing an app for just one person makes sense, if that person is the lab head scientist, or the CTO, or the VP of informatics. Doing it in a reasonable time might happen if I can use Cocoa and can leverage all the goodies that the frameworks provide.

So, Rusian, good luck! If you integrate CD with Valentina, or provide a useful perspective for the CD team, my evil ends will be advanced.

Scott
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden


References: 
 >Re: Extension of CoreData to third party databases. (From: Ruslan Zasukhin <email@hidden>)
 >Re: Extension of CoreData to third party databases. (From: Bill Bumgarner <email@hidden>)

  • Prev by Date: Re: Is Apple's singleton sample code correct?
  • Next by Date: NSTextView and setUsesFontPanel:
  • Previous by thread: Re: Extension of CoreData to third party databases.
  • Next by thread: Re: [NSApp mainMenu] returns nil
  • Index(es):
    • Date
    • Thread