RubyMotion에서 CoreData로 스키마 마이그레이션을 수행하는 방법을 연구했습니다.RubyMotion에서 CoreData 마이그레이션 문제
CoreData 스키마 마이그레이션의 문제는 평범한 Obj-C iOS 개발자이고 평범한 사람이라면 일반적으로 XCode를 통해 이루어집니다. RubyMotion을 사용하고 있으므로 수동으로해야합니다.
XCode CoreData 프로젝트에는 응용 프로그램의 엔티티와 속성을 보여주는 다이어그램 모양의 그래프 인 xcdatamodel 파일이있어 개발자가 추가/수정할 수 있습니다. 버전이있는 xcdatamodel 파일을 만들고 한 버전에서 다른 버전으로 마이그레이션을 설정할 수 있습니다. Lightweight Migration http://developer.apple.com/library/ios/#documentation/cocoa/Conceptual/CoreDataVersioning/Articles/vmLightweightMigration.html이라는 기능을 제공하며 마이그레이션 범위가 제한 범위 내에있는 한 자동 마이그레이션을 수행 할 수 있습니다.
이러한 기능은 XCode 및 xcdatamodel 파일이있는 프로젝트에서만 사용할 수 있습니다. CoreData의 속성 및 속성을 정의 할 때의 현재 구현은 모두 코드에 정의되어 있습니다. 그러나이 접근 방식은 CoreData의 구조를 정의하는 XCode 방식을 사용하지 못하게하므로 XCode를 통한 마이그레이션 처리를 제공하지 않습니다. 는 여기에 내가 CoreData의 스키마 (등 엔티티, 속성)을 정의하고 경량의 마이그레이션을 수행하는 엑스 코드를 사용하여 지금까지
사용 xcdatamodel 파일을 온 잠재적 인 방법을 제공합니다. Nitron은 모델을 정의하기 위해 xcdatamodel 파일을 참조합니다. 나는 아직 얼마나 몰라. (Nitron https://github.com/mattgreen/nitron/issues/27의 작성자에게 질문을 올렸지 만 그가 어떤 반응을 보이는지는 아직 알 수 없습니다.) Xcodeproj https://github.com/CocoaPods/Xcodeproj이라는 루비에서 Xcode 프로젝트와 상호 작용할 수있는 것처럼 보이는 보석이 있지만 만들지 못했습니다 일이나 많은 시간을 보냈다.
코드에서 수동 마이그레이션을 수행하는 것이 이론적으로 가능합니다. 우리가 가질 필요가있는 것은 원래 managedObjectModel과 대상 managedObjectModel이며 "모델을 자동으로 찾을 수없는 경우 마이그레이션 관리자 사용"에서 설명하는 단계를 따르십시오. http://developer.apple.com/library/ios/#documentation/cocoa/Conceptual/CoreDataVersioning/Articles/vmLightweightMigration.html 문제는 원래 managedObjectModel을 얻는 방법입니다. db/migrate/*에서 ruby-on-rails이하는 것처럼 NSManagedObjectModels의 모든 버전을 저장해야합니다. 현재 NSManagedObjectModel과 대상의 NSManagedObjectModel을 가지고 있으면 마이그레이션이 가능합니다. NSManagedObjectModel의 모든 버전을 저장하는 한 가지 방법은 키 - 값 기반 지속성 저장소에 있습니다. 배열과 사전을 저장할 수있는 NanoStore https://github.com/siuying/NanoStoreInMotion이라는 멋진 보석이 있습니다. 그래서 각 버전을 배열에 저장하고 중첩 된 사전 형식으로 스키마를 설명 할 수 있습니다. 나는 그것을 연습하기 위해 코딩을하지 않았지만 이것이 하나의 접근이라고 생각합니다.
키 데이터 저장 및 키 - 값 기반 저장으로 이동하십시오. NanoStore는 매우 강력 해 보이며 sqlite가 뒷받침하는 지속성 데이터 저장소입니다. readme에서 보여 주듯이, 속성이있는 모델을 만들 수 있고
find일을 할 수 있으며 bag이라는 객체 컬렉션을 만들고 그 작업을 수행 할 수 있습니다. 각 모델에는 관계가 없음에도 불구하고, 우리는 잠재적으로 객체를 연결하는 가방을 사용할 수 있습니다 및/또는 우리는 내가 여기에 내가 키 - 값 저장소 때문에 주로쪽으로 생각이 기울고 있어요 https://gist.github.com/4042753
을 어떻게처럼, 우리 자신의 관계를 정의 할 수 있습니다 그것의 간명의 그러나 아직도 끈기에 온다. 스키마 변경으로 어떻게 처리됩니까?기존 데이터에 속성을 추가/제거합니다 (속성을 제거하면 모든 열을 삭제하고 기존 모델 인스턴스에 새 속성을 추가하는 경우에는 nil). 이게 나쁜가요? 우리가 수 필요한 경우 서버에서 객체를 동기화 할 수 있기 때문에 나쁘다고 생각하지 않습니다 (우리의 응용 프로그램은 서버 기반 응용 프로그램입니다).
어떻게 생각하십니까?
우리는 같은 딜레마를 다루고 있으며 지금 당장 1 번 접근법을 시도 할 것입니다. 미래의 일관성 및 성능 문제로 이어질 까봐 걱정됩니다. 또한 # 3은 데이터베이스 버전 간의 마이그레이션을 관리하기 위해 일부 프로세스가 필요하기 때문에 원래의 문제를 해결해야합니다. 우리가 어딘가에서 실제 예제를 얻을 때까지 # 2는 옵션이 아닙니다. –
그것이 내가 마침내 앉아서 MotionModel을 작성하게 한 딜레마입니다. [면도 야크] –