What The Heck Is "Core Data" ... ?

Posted:
in Mac Software edited January 2014
... and should I be getting exicited?



I'm coding currently in WebObjects, and sure, EOF is pretty snazz [if you have the time, a company that's willing to subsidize your NSLearningCurve] ... and being able to use the huge Java library with is is also, very snazz ...



But web interfaces for business apps are, well, not the best, and using Java Clients is only somewhat better ...



So, to be honest, being a little out-of-the-loop (forgive me)I've heard what sounds like rumblins of Core Data being a kind of vastly expanded 21st century version of EOF, written in Obj-C, that would do wonders to solve the enterprise software problems, and would likely integrate with many other software packages that one at first blush would never assume to benefit much from Enterprise abilities - yet somehow, vastly extending their powers.



Is it a dream?

Thanks In Advance

OT

Comments

  • Reply 1 of 18
    kickahakickaha Posts: 8,760member
    CoreData is essentially EOFLite. It lets you serialize data as XML, binary, or into an SQLLite database. Your choices of DB are limited, but it's easy enough to use (very small NSLearningCurve ), that most every developer will start using it quickly, I would think. I know I will.



    And yes, the interoperation possibilities between apps are about to get frighteningly wonderful.
  • Reply 2 of 18
    So it will be easier for one application that uses CoreData to talk to another application also using Core Data to share data back and forth? Sorta like how iLife's apps all connect to each other's libraries?



    Mike
  • Reply 3 of 18
    Quote:

    Originally posted by MPMoriarty

    So it will be easier for one application that uses CoreData to talk to another application also using Core Data to share data back and forth? Sorta like how iLife's apps all connect to each other's libraries?



    Core Data will not make inter-app interaction any easier. The only thing it will do is to allow people to build small database-backed applications quicker. Just because two applications use a particular database (say MySQL) does not make it easier for those two applications to talk to another... You still have to do all the work... and playing with another application's underlying data is a very dangerous proposition unless there is a lot of consistency-keeping work going on.
  • Reply 4 of 18
    amorphamorph Posts: 7,112member
    Quote:

    Originally posted by MPMoriarty

    So it will be easier for one application that uses CoreData to talk to another application also using Core Data to share data back and forth? Sorta like how iLife's apps all connect to each other's libraries?



    It's possible. Apparently, the iLife apps already communicate with each other by passing XML around, so it seems like a straightforward enough evolution to serialize (I prefer Python's term: pickle) your data and hand it off to another app that can read it with a trivial translation layer, all through Core Data.



    That's wide-open speculation, though, since I can't poke at Core Data myself. Yet.
  • Reply 5 of 18
    kickahakickaha Posts: 8,760member
    CoreData allows you to publish your object model. Others can load it. That's pretty much as transparent as you can get. Woot.



    Seriously, nothing is ever going to make it painless, but this is a huge leap forward for having applications share data.
  • Reply 6 of 18
    Ok, if CoreData is not going to make applications able to communicate better with each other, why does everyone I hear talking about it keep pushing this benefit?



    Is CoreData just an easy way to make database backends for your applications?



    Mike
  • Reply 7 of 18
    Quote:

    Originally posted by MPMoriarty

    Ok, if CoreData is not going to make applications able to communicate better with each other, why does everyone I hear talking about it keep pushing this benefit?



    Is CoreData just an easy way to make database backends for your applications?



    Mike




    ... actually, if I've read Kickaha's comments correct, being able to load up a complete foreign object graph, and make use of it - rather than just writing to an API - will make all kinds of sharing between apps that make use of Core Data much easier.



    That is, if I've understood correctly?
  • Reply 8 of 18
    buonrottobuonrotto Posts: 6,368member
    What I gather is that primarily, it just makes database backends easier as you said, but, if people take the effort and commmnicate how their db works, then others can tap into this backend as well. I guess that since the toolbox for these db backends is standardized to some degree, that making these bds speak to one another becomes easier, but it isn't automatic and they don't all speak the same language despite having the same, uh, alphabet of sorts. That's my story until someone comes in here and corrects me, anyway.
  • Reply 9 of 18
    frank777frank777 Posts: 5,839member
    If Core Data handles database functions as said here, does that mean somebody can use it to build that Cocoa spreadsheet app I so desperately want?
  • Reply 10 of 18
    kickahakickaha Posts: 8,760member
    Well, um, first off, a database and a spreadsheet are two very different beasts at heart.



    Secondly, CoreData isn't a database *engine*, it's just a way of getting your data between disk and application - a way to save files easily... it just so happens that one of those ways is saving it to a database *format*.



    SQLLite will be the actual database, not CoreData.
  • Reply 11 of 18
    frank777frank777 Posts: 5,839member
    My bad.



    Some of my reading lately led me to believe that a spreadsheet and database were similar when viewed from the back-end of things. As you see, I've never written a line of code in my life.
  • Reply 12 of 18
    kickahakickaha Posts: 8,760member
    Well you can create a simplistic table-based database with singular axes in two coordinates and call that a spreadsheet... but that'd be silly.
  • Reply 13 of 18
    pbg4 dudepbg4 dude Posts: 1,611member
    Quote:

    Originally posted by Kickaha

    Well you can create a simplistic table-based database with singular axes in two coordinates and call that a spreadsheet... but that'd be silly.



    Not to mention denormalized, which is the antithesis of database design.
  • Reply 14 of 18
    pbg4 dudepbg4 dude Posts: 1,611member
    Quote:

    Originally posted by Kickaha

    Well, um, first off, a database and a spreadsheet are two very different beasts at heart.



    Secondly, CoreData isn't a database *engine*, it's just a way of getting your data between disk and application - a way to save files easily... it just so happens that one of those ways is saving it to a database *format*.



    SQLLite will be the actual database, not CoreData.




    But if CoreData can pass data schemas around, then could someone analyze the schemas for Mail & iCal and create a new front end for this data?



    Going a little furthur () down this road, could an app kickstart Mail and have it download all the new mail, then pull this data? Maybe somehow add email appointment addition functionality like what's available in Notes? Will we finally be able to set, request, accept or deny appointments without using MS Entourage?
  • Reply 15 of 18
    The demonstration of Core Data I saw in the WWDC sessions is really impressive. CoreData provide a concept of Entity. An Entity is a class that is bound to a table of the database. for exampe, you can drag a XML file to Xcode and Xcode will automatically generates the Entity graph. If you modify the source of these Entity, the graph is updated. If you update the graph, the source is modified.



    But the most interesting part was that you can drag an entity to a window in interface builder and the user interface need to update/edit/list the data in the entity will be automatically created. The Undo/Redo functions is even handled for free.



    CoreData work seemlessly with the Model/View/Controller of IB.



    The guys doing the demo said something like : it's EOF done right.



    It's really powerfull cause it will shorten development. But something I've not seen mention is its ability to be expanded beyong the Binary/SQLLite/XML storage. I would like to see the capacity to use JDBC/ODBC/native database support. The ability to write SQL adaptor for CodeData.



    I think we will see this someday (for the final release or in the next major OS release).



    But the big thing is that it was really impressive in term of simplicity. It's the kind of thing you figure out really quickly. Not that kind of concept that take days to figure out...
  • Reply 16 of 18
    kickahakickaha Posts: 8,760member
    I think what you'll see is CoreData as the consumer OS technology, and a beefed up version with DB abstraction as the kernel of a vastly revamped WebObjects. One base technology to maintain, but two different levels of power for two very different markets.
  • Reply 17 of 18
    Quote:

    Originally posted by Kickaha

    I think what you'll see is CoreData as the consumer OS technology, and a beefed up version with DB abstraction as the kernel of a vastly revamped WebObjects. One base technology to maintain, but two different levels of power for two very different markets.



    Drool.



    Though, this sounds like they're just - more or less - doing what NeXT was doing a decade ago, but including better compatability with XML and few other modern conveiniences ...



    Not that that's necessarily underwhelming - in fact it could be a very powerful thing: but is that in fact,what it is?



    Where do you go to read about this stuff - a quick search of Apple's dev pages didn't turn up much.



    A FAQ, A FAQ, My Kingdom for a FAQ!
  • Reply 18 of 18
    We read this in the document apple send us because we are registered apple developer. We got informations before there are public.



    CoreData in not a revolution, for the most part it does what other data access framework does.



    But the interesting thing is that it is done the apple way that is: any developer can use it very easy to handle the persistence of its data and the related mechanisms.



    It could shorten the time needed to develop an application (if it doesn't need to be ported to other platforms).



    With others technologies like Core Image/Core Video, it bring to the hand of developers powerfull yet simple API to build tomorow applications.
Sign In or Register to comment.