FROM : Scott Ellsworth
DATE : Mon Jun 05 20:01:45 2006
On Jun 5, 2006, at 9:18 AM, Paul Lynch wrote:
>
> On 5 Jun 2006, at 16:37, kyle kinkade wrote:
>
>> too me it feels like with Core Data you didn't really have too
>> much control with the data. it seemed like you built your models,
>> plugged everything together with interface builder, and that was
>> it, but i really wanted more from it, in the sense of having more
>> direct access. and the resulting database file would need to be
>> exchanged with other platforms.
>
> [...]
> Other platforms should be able to read your database; but you may
> have problems using Core Data on an SQLite database created elsewhere.
To be fair, though, Core Data does have limitations in its current
release, based on the role Apple envisions for it.
It has a very specific schema design - it does not allow you to use a
natural PK, for example. All objects are referred to by an opaque
object id. This fits well with WO, and can work quite well, but if
you intend to interact with data stores without this arbitrary object
id column, say via hibernate, you will be fighting the framework a bit.
Further, Apple does not promise to keep the schema as represented in
the sqlite file unchanged with future releases. Were I trying to
model something that is meant to be read on many platforms, I would
be very cautious about using a toolkit that might change schema on
me. I might still use it, but when part of a cross platform app is a
single platform toolkit, I budget some engineering to make sure they
play nice.
Finally, there are optimizations that SQLite allows, but that Core
Data does not. For example,
NSNumber * normCol = [NSNumber numberWithInt:1];
NSPredicate *predicate = [NSPredicate predicateWithFormat:@"(abs(%@ -
normalizedColumn) / 2 < %@)", normCol, [NSNumber numberWithInt:3]];
where normalizedColumn is a column in my Core Data model. SQLite can
handle this quite well - 'select * from foo where abs(1 -
normalizedColumn) / 2 < 3)' and you will get results back in
moments. The mapping from this NSPredicate to the appropriate sqlite
calls is not there, so it is not easy to do with CD.
That said, Core Data does a lot of things very well. I would not
look at it as a general interface to SQLite, though, as yet. I would
look at it as an elegant solution for the data model problem Apple
was targeting. I do hope that last is addressed some day, but we
shall see.
Scott
DATE : Mon Jun 05 20:01:45 2006
On Jun 5, 2006, at 9:18 AM, Paul Lynch wrote:
>
> On 5 Jun 2006, at 16:37, kyle kinkade wrote:
>
>> too me it feels like with Core Data you didn't really have too
>> much control with the data. it seemed like you built your models,
>> plugged everything together with interface builder, and that was
>> it, but i really wanted more from it, in the sense of having more
>> direct access. and the resulting database file would need to be
>> exchanged with other platforms.
>
> [...]
> Other platforms should be able to read your database; but you may
> have problems using Core Data on an SQLite database created elsewhere.
To be fair, though, Core Data does have limitations in its current
release, based on the role Apple envisions for it.
It has a very specific schema design - it does not allow you to use a
natural PK, for example. All objects are referred to by an opaque
object id. This fits well with WO, and can work quite well, but if
you intend to interact with data stores without this arbitrary object
id column, say via hibernate, you will be fighting the framework a bit.
Further, Apple does not promise to keep the schema as represented in
the sqlite file unchanged with future releases. Were I trying to
model something that is meant to be read on many platforms, I would
be very cautious about using a toolkit that might change schema on
me. I might still use it, but when part of a cross platform app is a
single platform toolkit, I budget some engineering to make sure they
play nice.
Finally, there are optimizations that SQLite allows, but that Core
Data does not. For example,
NSNumber * normCol = [NSNumber numberWithInt:1];
NSPredicate *predicate = [NSPredicate predicateWithFormat:@"(abs(%@ -
normalizedColumn) / 2 < %@)", normCol, [NSNumber numberWithInt:3]];
where normalizedColumn is a column in my Core Data model. SQLite can
handle this quite well - 'select * from foo where abs(1 -
normalizedColumn) / 2 < 3)' and you will get results back in
moments. The mapping from this NSPredicate to the appropriate sqlite
calls is not there, so it is not easy to do with CD.
That said, Core Data does a lot of things very well. I would not
look at it as a general interface to SQLite, though, as yet. I would
look at it as an elegant solution for the data model problem Apple
was targeting. I do hope that last is addressed some day, but we
shall see.
Scott
| Related mails | Author | Date |
|---|---|---|
| kyle kinkade | Jun 5, 17:21 | |
| Paul Lynch | Jun 5, 17:31 | |
| kyle kinkade | Jun 5, 17:37 | |
| Paul Lynch | Jun 5, 18:18 | |
| Scott Ellsworth | Jun 5, 20:01 |






Cocoa mail archive

