Skip to content
This repository

README file needs improvements about how to save #307

Closed
fgarcia opened this Issue November 13, 2012 · 3 comments

3 participants

Francisco Garcia Tony Arnold bcyng
Francisco Garcia

The quickstart in the README file needs to make clear how to save back to the persistent store.

The linked tutorials also do not make this point clear

There are comments about how to save a single or a group of nested context. But it is more natural to ignore searching for the context and use one of the [MagicalRecord save...]

Just cleanUp is not enough and it should be clear which saving option is blocking. Specially when terminating the program and the code must wait to know if everything was saved OK


UPDATE: I also posted some problems I had saving here:

#297 (comment)

I also tried [Magical saveWithBlock:] and I lost data. The only solution I can find now to safely store all changes is by doing what I wrote in that comment. I would expect [Magical saveWithBlock:] to be non blocking, but it would be even better having a non blocking save that returns BOOL upon completion. That is how NSManagedObject context save works. Also returning a success value clearly indicates that the function is blocking until completion.

bcyng

all the saves seem to be broken in latests version. i've got a simple project i use for data conversions using a single context that stopped saving with 2.0.8. so i dropped in a version of magical record from a few months ago and it worked perfectly.
suggest you switch back to pre 2.0.8 until the ops get it sorted out. I havent been able to figure out why its broken.

Tony Arnold
Owner

Just cleanUp is not enough and it should be clear which saving option is blocking. Specially when terminating the program and the code must wait to know if everything was saved OK

Most of the time cleanUp should be enough. If you're not saving changes to your persistent store as they are made (or at well thought out points in the flow of your app), your users will lose data. Don't rely on the app's state changing before saving changes — this will definitely result in data loss if your app ever crashes, or the user kills the app manually.

I would expect [Magical saveWithBlock:] to be non blocking, but it would be even better having a non blocking save that returns BOOL upon completion.

As for the saveWithBlock: method blocking, that's by design. The non-blocking methods all contain some variant of InBackground in their name (i.e. saveInBackgroundWithBlock:) so it's pretty clear what's happening if you have a look at the headers, and at the section of the readme titled "Performing Core Data operations on Threads". MagicalRecord's method names predate Apple's new performBlock: and performBlockAndWait: methods and are simply inverted (and have been for some time). Should MagicalRecord make a breaking change to match Apple's approach? Yeah, probably — but it's a reasonably big change to the API. It'd be better to wait for MagicalRecord 3.x to do this.

Point taken on the documentation — it could always be better. You're welcome to suggest changes via a pull request, or wait for one of the team to jump in and do it.

Tony Arnold
Owner

I've opened a specific issue to do this for MagicalRecord 2.1: #342. If there's anything specific you'd like covered, please add it to that issue.

Tony Arnold tonyarnold closed this December 14, 2012
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.