Update ReadMe.md to help prevent crashes with large databases.

[JHumphreyJr]

I recommend updating the ReadMe.md to include waiting after the applicationDidFinishLaunching:(UIApplication *) withOptions:(NSDictionary *) method to setup/migrate large databases for iOS devices. The reason is because large databases, especially on slower iPads (iPad 1 and early iPad 2s), may take a long time to setup or migrate. If it takes too long Apple will kill the application with a "[appname] failed to launch in time" before the setup/migration finishes. Here are some related Stack Overflow posts.

http://stackoverflow.com/questions/7641742/ios-core-data-migration-time-out
http://stackoverflow.com/questions/2860310/iphone-app-launch-times-and-core-data-migration
http://stackoverflow.com/questions/2160848/core-data-causing-app-to-crash-while-migrating

[casademora]

This seems to only happen on migrations, not "large databases". Just want to clear up the cause since Core Data doesn't load anything other than the stack objects when it launches and connects to a persistence store. That is, only the stack is created, which points to the data on disk. All that data stays there until you fetch it. Migrations on the other hand, need to load (transfer) all the data from one persistent store to the new, migrated version. All that data loads into memory and could take a while. The proper solution would be to update the MagicalRecord setup methods that have migrations enabled, and perform those in a background thread so that applicationDidFinishLanching can complete. Then a notification or block callback can then finish loading the rest of the app...

On Nov 7, 2012, at 8:00 AM, JHumphreyJr notifications@github.com wrote:

I recommend updating the ReadMe.md to include waiting after the applicationDidFinishLaunching:(UIApplication *) withOptions:(NSDictionary *) method to setup the database for iOS devices. The reason is because large databases, especially on slower iPads (iPad 1, early iPad 2's), may take a long time to setup or migrate. If it takes to long Apple will kill the application before the setup/migration finishes. Here are some related Stack Overflow posts.

http://stackoverflow.com/questions/7641742/ios-core-data-migration-time-out
http://stackoverflow.com/questions/2860310/iphone-app-launch-times-and-core-data-migration
http://stackoverflow.com/questions/2160848/core-data-causing-app-to-crash-while-migrating

—
Reply to this email directly or view it on GitHub.

[JHumphreyJr]

Thanks for the response. When I was referring to the setup of large databases I was referring to any logic a user may decide to run immediately after initial setup to load large amounts of data. While that is outside of the API, I believe some sort of mentioning of special handling for large databases should be included in the ReadMe. I am also not sure if a background migration would work well without mechanisms to alert the application when the database is ready. To fix the problem in my application I postponed the Core Data migration until the next run loop by calling -[NSObject performSelectorOnMainThread:withObject:waitUntilDone];. Just hoping to help prevent others from having this issue in the future.

[casademora]

Alerting users to migrations are probably not common or ideal.
Your solution is probably similar to an approach MagicalRecord should take when performing a data migration.

On Nov 7, 2012, at 11:18 AM, JHumphreyJr notifications@github.com wrote:

Thanks for the response. When I was referring to the setup of large databases I was referring to any logic a user may decide to run immediately after initial setup to load large amounts of data. While that is outside of the API, I believe some sort of mentioning of special handling for large databases should be included in the ReadMe. I am also not sure if a background migration would work well without mechanisms to alert the application when the database is ready. To fix the problem in my application I postponed the Core Data migration until the next run loop by calling -[NSObject performSelectorOnMainThread:withObject:waitUntilDone];. Just hoping to help others with this issue in the future.

—
Reply to this email directly or view it on GitHub.

[JHumphreyJr]

By user I meant developer and by alert I meant NSNotification, delegate or a block callback. The necessity to delay migration for larger databases would introduce more complexity into the API. The reason is because the developer will have to make sure not to make any API calls until the data is migrated. I created a gist of essentially what I had to do to make this work here: https://gist.github.com/4033674.

If you look at what I needed to do you can see that the developer will have to make sure to not make any Core Data calls or create any classes that make Core Data calls, especially since it is easy to grab the default context using [NSManagedObjectContext MR_defaultContext];. If this kind of functionality gets included in the API there would need to be a way for developers to check if the context is ready for use and register for some kind of callback when it is not ready. The other concern is what happens when the context is not ready? Return nil or nil and an NSError or throw an exception? I do realize the current implementation uses an assertion and returns nil which would still work.

[tonyarnold]

Given the age of this issue, and the volume of issues we have to work through, I've decided to close this alongside a number of other older issues.

If you can still replicate the issue under the latest in-development version of MagicalRecord (3.0 at the time of writing), please feel free to re-open and one of @magicalpanda/team-magicalrecord will take another look. Thanks!

[bpoplauschi]

@tonyarnold this issue still occurs, for instance migrating a large database (50MB) triggers a watchdog crash. This is due to the fact that [MagicalRecord setupAutoMigratingCoreDataStack] is called from application:didFinishLaunchingWithOptions:.