SQL-PO -> Core Data Migration?

[mike]

I'd like to continue to use SQL-PO for the first release of my app,
and then probably move to Core Data in a future version. Even
though I don't think I'll have my app finished and ready for the app
store before general availability of 3.0, I would like to get it to
beta testers before then, and I don't know what the 3.0 adoption curve
will look like after it's released. So I'm a little hesitant to jump
into Core Data now with both feet, but might end up being forced to do
so if I can't figure out a data migration strategy.

If users create a lot of data using my app, and I'm storing it with
SQL-PO, then how am I going to handle that in "version 2" of the app,
where model objects are Core Data rather than SQL-PO?

I haven't studied Core Data in any detail yet, but it seems that my
objects in Version 2 will need to be subclasses of NSManagedObject.
My current model objects are instances of SQLLitePersistentObject, and
Objective-C doesn't allow for multiple inheritance -- so I don't see
that there is any clear way for me to move my objects forward to Core
Data but still allow them to have compatibility with older data stored
via SQL-PO.

Does anyone have a recommendation of a good way to approach this?

Thanks,
Mike

[Andrew]

Mike,

This is a problem all of us face. And I think there are some rather
straight forward solutions.

1) First, there is nothing precluding you keeping SQL-PO code in your
next version as part of your migration strategy.

2) Second, your problem really is about your SQL schemas and making
sure Core Data can read your SQL-PO tables. I really doubt that this
is a hard problem. Furthermore, I suspect that your current object
declarations probably have an almost one to one and onto mapping
between the two worlds for simple object graphs.

3) An incremental/background data migration process early in the new
version's existence on a user's device is probably all you need.
Unless your data bases are really huge (> 100's of MB), I suspect this
is a fast process.

> Does anyone have a recommendation of a good way to approach this?

I think you may have just stepped up to be our first explorer into the
transition jungle. I look forward to your reports back to this list.

Andrew

[Ken]

I am interested in how this turns out for you. Although I am doing my
homework on OS 3.0 and am excited about the inclusion of Core Data,
I'm not yet able to test SDK 3.0, since installing SDK 3.0 keeps you
from submitting 2.x apps to the App Store. Since I only have one
machine for development, that effectively keeps me locked into 2.x for
now. If you can share your findings, I would very much appreciate
it.

Relatedly, I don't think SQLPO is going anywhere. I think most people
will want to continue to support OS 2.x users, and as such, cannot
rely exclusively on Core Data for their ORM/persistence needs. The
idea I'm currently tossing around is having two sets of business
objects (those based on Core Data, and those based on SQLPO), and
having the application work with the right ones depending on what OS
version it's running on. I think that's the only way I can maintain a
single app branch and codebase. Does anyone have any better ideas?

KM

[Hunter Hillegas]

You can install two sets of the SDK on one machine - specify the
directory for 3.0 at install to be something like 'Developer3' instead
of the default.