problems with CoreData migrations in RubyMotion - core-data-migration

Question

I have been researching through how I can do schema migrations with CoreData in RubyMotion.
the problem with CoreData schema migration is that normally it is done through XCode if you are ordinary Obj-­C iOS developer and life is good. but since we are with RubyMotion, we have to do this manually.
XCode CoreData project comes with xcdatamodel files which are diagram-­looking graph that shows entities and properties of an app, letting you add/modify them. you can create a versioned xcdatamodel files and be able to set up a migration from one version to another; it  offers a feature called Lightweight Migration  http://developer.apple.com/library/ios/#documentation/cocoa/Conceptual/CoreDataVersioning/Articles/vmLightweightMigration.html which can perform automatic migrations as long as a scope of the migration is within its limit.
These features are only available in XCode and projects with xcdatamodel files.
My current implementation with defining CoreData's attributes and properties are all defined  in code. but this approach would not  let  us  use  XCode  way  of  defining  CoreData's  structure  and  therefore  not  providing migration  handling  through  XCode.
here  are  potential  approaches  I  came  up  so  far
 use  xcdatamodel  files  to  define  CoreData's  schema  (entities,  properties  etc)  and  use  XCode  to  do  lightweight migrations.
Nitron  is  referencing  xcdatamodel  files  to  define  models; I  just  don't  know  how  yet. (posted  a  question  to  the  author  of  Nitron  https://github.com/mattgreen/nitron/issues/27  to  get  more  insight  on how  he  does  it  but  no  response  yet.) there  is  also  a  gem  called  Xcodeproj  https://github.com/CocoaPods/Xcodeproj  which  does  look  like  you  can interact  with  XCode  project  from  ruby  but  did  not  make  it  work  nor  spent  much  time  yet.
 do  manual  migration  in  code this  is  theoretically  possible.  what  we  need  to  have  is  an  original  managedObjectModel  and destination  managedObjectModel  and  follow  steps  describe  in  "Use  a  Migration  Manager  if  Models  Cannot  Be Found  Automatically"  http://developer.apple.com/library/ios/#documentation/cocoa/Conceptual/CoreDataVersioning/Articles/vmLightweightMigration.html
Problem  here  is  how  to  get  original  managedObjectModel.  we  need  to  store  all  versions of  NSManagedObjectModels,  just  like  how  ruby-­on-­rails  does  in  db/migrate/*. having  current  NSManagedObjectModel  and  destination's  NSManagedObjectModel,  migration  is  possible. one  way  of  storing  all  versions  of  NSManagedObjectModel  is  in  key-­value  based  persistence  storage. there  is  a  nice  gem  called  NanoStore  https://github.com/siuying/NanoStoreInMotion which  let  you  store  array  and  dictionary.  so  we  can  store  each  version  in  an  array  and  describe  schema  in  nested dictionary  format,  for  example.  I  have  not  done  coding  to  exercise  that,  but  I  presume  this  is  one  approach.
 fuck  coredata  and  move  on  with  key-­value  based  storage. NanoStore  looks  very  powerful  and  it  is  persistence  data  storage,  backed  by  sqlite.  as  readme  shows,  it  can create  models  with  attributes,  being  able  to  find  things,  and  can  create  a  collection  of  objects  called  bags  and do  operations  with  them.  although  there  is  no  relationship  with  each  models,  we  can  potentially  use  bags  to associate  objects  and/or  we  can  define  our  own  relationships,  like  how  I  do  here  https://gist.github.com/4042753
I  am  leaning  towards  key-value store  mainly  because  of  its  simplicity  and  yet  still  comes  with  persistence.  how  does it  handle  with  schema  change?  it  just  add/remove  attributes  to  existing  data  (delete  all  columns  if  you  remove attributes  and  nil  if  you  add  a  new  attribute  to  existing  model  instances).  is  this  bad?  I  dont  think  it is  necessary  bad  since  we  could  sync  objects  from  server  if  necessary (our app is server-based app).
what do you think?

Answer 1

For creating xcdatamodel files you can use ruby-xcdm which makes it easy to manage multiple schema versions in an ActiveRecord-like way.
Then from the same author you have Core Data Query which abstracts away a lot of the complexity you would otherwise need to handle manually.
Another resource to take a look at it this example of how to set up (lightweight) migrations manually, purely in code without any assistance from Xcode.
There's also a chapter in Core Data 2nd Edition by Marcus Zarra that takes you through how to set up your migrations so that they run in order, which reduces the complexity once you're several schema versions down the line. That's in Objective-C but it's relatively straightforward to port this to RubyMotion.