I'm using SSDataKit along with AFIncrementalStore and discover interesting behavior.

Seems like when NSFetchedResultController performing fetch, implicitly uses topmost PSC of parent/child MOC chain. I swizzle -executeRequest:withContext:error: method of NSPersistentStoreCoordinator, and it is called with privateQueueContext as context parameter, while NSFetchedResultController is initialized with mainQueueContext.

AFIncrementalStore can intercept fetch requests and change context before (or after in async manner) returning any results back to caller. In my case NSIncrementalStore method -executeRequest:withContext:error: is also called with privateQueueContext as parameter. Then AFIncrementalStore getting data from remote server and update privateQueueContext asynchronously. But this changes never automatically pulled by mainQueueContext.

Now I just override -mainQueueContext method to not use private moc as parent, but looking for more appropriate solution to pull changes back to main moc in case of async update in private moc.

Hi, my app works fine with SSDataKit but when I try to run some Unit Tests, I get the exception

An NSManagedObject of class 'XXXX' must have a valid NSEntityDescription.

when instantiating a new managed object. My model definition is included in the test target.

any idea what is wrong?

cheers

I'm using SSDataKit for a little project of mine, but needed to use UICollectionViewCollection instead of UITableViewController - so I decided to implement it myself.

Everything works. Very similar API to UITableView.

So here's how to reproduce the bug.

1. In my podfile, I have ~> 0.3.0.
2. If I run pod update nothing gets updated. I still have the old code.
3. Tried deleting the Pod-SSDataKit directory and re-run pod install and pod update
4. Still gets the same, old version.

I have cocoapods 0.29 BTW. Tried sudo gem install/update cocoapods without any luck.

Should I just do git pull origin master in the pod directory ?

Thanks a lot.

Just ran into this issue and wanted to get an issue started, PR coming soon.

Method: DateTime.now.utc.to_s Format: 2014-09-11T20:58:54+00:00

An offset of zero, in addition to having the special representation "Z", can also be stated numerically as "+00:00", "+0000", or "+00".

• ISO 8601 - Time offsets from UTC

Hits this condition in SSRemoteManagedObject and method is like

I work with a lot of (subpar) APIs. Some are nicer than others, but one I'm working with in particular sends all JSON over as string values, no integers. With remoteIDs, this causes a crash when the value for @"id" is a string and not an int. Easy enough to just cast it.

I referenced the parser in SSToolkit and it looks like there's a typo.

There are no tests, but without this change, my dates (from Rails to_json) aren't able to be parsed. After the change, everything works fine.

I can't make it work in my cocoa app because UIKit library, errors located at: SSFilteredResultsFilter.m and SSFilterableFetchedResultsController.h

How should I handle this?

.../SSDataKit/SSFilterableFetchedResultsController.h:10:9: fatal error: 'UIKit/UIKit.h' file not found
#import <UIKit/UIKit.h>
        ^
1 error generated.

See issue #29 for why I made this change. In short, this patch just deletes the -wal and -shm files created by SQLite WAL mode. (Enabled by default on iOS7.)

I couldn't easily include my tests for this, because of the the way the SSDataKit tests are structured. But I did test this patch for both WAL mode and DELETE mode. Unfortunately, I was not able to test on older versions of iOS, but it should be just fine. As you can see, there isn't much too it.

I made the following changes:

• I think that performing two sets of batch updates in controllerDidChangeContent: is dangerous. At the end of the first update, the collection view could ask the data source for data that is now outdated which will cause a crash. I folded both update blocks into a single pass. #24
• I don't like the idea of using the mutable collections directly inside the change block since no garuntee is made as to when it will run. So, I copy the pending changes into stack variables and immeditely reset the mutable collections. This prevents the collections from being mutated in multiple quick passes through the fetched results controller methods. #24
• Added ability to disable change animations. #25
• Begin translating index paths from fetched index paths into view index paths. #24.
• Translate group indexes from fetched indexes to view indexes so that the appropriate groups are updated. #24

This addresses #35. Since you recommended using the ISO8601 lib for date parsing it seemed appropriate that SSDataKit use it as well. This PR adds Cocoapods to the test project and then updated the -parseDate: method to use the ISO8601 lib for when the input was a string.

~~NOTE: The 2 existing ISO8601 tests now fail, but my added test now passes.~~ Fixed.

There exists an issue that if the NSPersistentStroeCoordinator failed to add a persistent store, then the coordinator was in a bad state. In this case, the code just continued to use that coordinator even though it was in a bad state, and then performing fetches or saves on the coordinator would cause a crash.

The fix only sets the static coordinator upon successfully adding a persistentStore, otherwise leaving it as nil. The second part of this is making it so that if the coordinator is nil, we still allow the code to run to make a new one to it can try and make it again.

While running unit tests on my SSDataKit enabled project I was hitting some SQLite 522 'not an error' errors. Those unit tests were on iOS7 (which has WAL enabled by default) and the tests frequently run SSManagedObject +resetPersistentStore during setup.

Some Googling and StackExchange searching led me to a theory that this might be caused by WAL mode, and particularly by the inconsistent state caused by having a new sqlite database file created, but still having an old WAL journal. As part of exploring that theory, I modified SSDataKit to clean up those -shm -wal files used by WAL when SSDataKit resets the persistent store or is cleaning up after a failed lightweight migration.

That theory didn't pan out, but I wanted to offer those changes back to you regardless. (I'll send a pull request right after I submit this issue.) Feel free to reject the request if you know that SQLite will always do the right thing with just the sqlite file removed. (Which, in theory, it should be able to do.)

I want to make several larger changes to SSDataKit. Here's the list:

• [ ] Rename to DataKit or SAMDataKit
• [x] Make the primary key (currently remoteID) configurable #20
• [ ] Automatic unpacking by default (can override to customize)
• [ ] Figure out a better nested context solution #11
• [ ] Proper demo #1
• [x] Full documentation
• [ ] Test SSManagedObject
• [ ] Test SSRemoteManagedObject
• [ ] Test fetched results controller craziness

Currently, whenever there's an change in the filter in a SSFilterableFetchedResultsController, the entire table is deleted and the new results are filtered.

With this change, only objects that do not pass the new filter are deleted, objects that pass both filters are moved if necessary, and objects that only pass the new filter (but not the old one) are inserted.

Thanks for all your hard work on this project! It seriously helped my understanding and use of CoreData.