The whole idea behind core data is to allow you to store your data without having to learn SQL or pay attention to when to save something. That means that you will not have the full range of SQL exposed... just like the full range of SQL is not easy to use using Access. SQL is a really flexible thing, and those who need that flexibility need SQL, there is no getting around that. But most programs don't need that, they just need to map relations and have a persistence layer. This is what CoreData is aimed at.
Oh... and why do you think that having your data in a CoreData file (of any type) will automatically expose your data to Spotlight? They are completely different functions, and spotlight would still need something to map all of your data to categories it understands, and that is going to be really difficult with CoreData's SQLite format... the plist/xml one is conceivable (if very difficult for complex files). So far Apple has said that Spotlight will only work on individual files, Mail.app is moving to them, and I would presume that either they are special casing Addressbook, or that it is moving to vcard separate files.
Oh... there are a bunch of Access clones already being worked on in various linux based projects... none are ready for prime time yet. Why not go work on one of those, bring it to MacOS X?
Bummer on the lack of full SQL exposure. I guess I'm one of those few people who'd rather hammer out the actual SQL over drag-n-drop or other kinds of wizardlike interfaces. Working with PeopleSoft Financials, Contracts & Billing has made me quite proficient in SQL.
I thought that Core Data would expose the data to Spotlight. Yes, I would need to define the meanings behind the data depending on the way Spotlight operates. Jobs did mention .pdf text searching at WWDC so I figured Core Data would at least make the text data viewable by the Spotlight search engine. If I used MySQL, the data would be stored in a binary format and would be harder to search.
I didn't know there were clone projects in progress (but it does make sense). If you could point me to them I'd be happy to check them out.
The three big "Access clones" are all under the KDE umbrella: Kexi, Knoda, and Rekall.
All three have some growing up to do before they can start to really challenge FileMaker, or even Access. If I were to pick a horse right now, I would say Kexi.
Comments
Originally posted by Karl Kuehn
The whole idea behind core data is to allow you to store your data without having to learn SQL or pay attention to when to save something. That means that you will not have the full range of SQL exposed... just like the full range of SQL is not easy to use using Access. SQL is a really flexible thing, and those who need that flexibility need SQL, there is no getting around that. But most programs don't need that, they just need to map relations and have a persistence layer. This is what CoreData is aimed at.
Oh... and why do you think that having your data in a CoreData file (of any type) will automatically expose your data to Spotlight? They are completely different functions, and spotlight would still need something to map all of your data to categories it understands, and that is going to be really difficult with CoreData's SQLite format... the plist/xml one is conceivable (if very difficult for complex files). So far Apple has said that Spotlight will only work on individual files, Mail.app is moving to them, and I would presume that either they are special casing Addressbook, or that it is moving to vcard separate files.
Oh... there are a bunch of Access clones already being worked on in various linux based projects... none are ready for prime time yet. Why not go work on one of those, bring it to MacOS X?
Bummer on the lack of full SQL exposure. I guess I'm one of those few people who'd rather hammer out the actual SQL over drag-n-drop or other kinds of wizardlike interfaces. Working with PeopleSoft Financials, Contracts & Billing has made me quite proficient in SQL.
I thought that Core Data would expose the data to Spotlight. Yes, I would need to define the meanings behind the data depending on the way Spotlight operates. Jobs did mention .pdf text searching at WWDC so I figured Core Data would at least make the text data viewable by the Spotlight search engine. If I used MySQL, the data would be stored in a binary format and would be harder to search.
I didn't know there were clone projects in progress (but it does make sense). If you could point me to them I'd be happy to check them out.
All three have some growing up to do before they can start to really challenge FileMaker, or even Access. If I were to pick a horse right now, I would say Kexi.