This can happen when using keyPaths to traverse an object graph and is hard to anticipate when
defining mappings. RestKit will now perform a sanity check before recursively performing
relationship object mapping operation and will log a warning if the relationship targets
a collection containing another collection. At the debug logging level, RestKit will log
The fix for such scenarios is to use KVC collection operators (such as @unionOfObjects,
@unionOfArrays, etc.) to flatten the collection out into a collection of dictionaries.
* Builds on work started by @OpenFibers.
* Should eliminate all cache warnings.
* Added FileMD5Hash library for efficiently computing MD5 for files
* Extended RKParams to return composite MD5 for all attachments
* Implemented MD5 method on each RKParamsAttachment instance
* Updated RKRequest to utilize new MD5 sums and enabled cache keys for RKParams
These issues has been open for some time. I have added thorough unit test coverage
for scenarios of mutating the HTTP AUTH credentials on the RKClient and on individual
RKRequest instances. Everything seems to work fine.
Also added RKAuthenticationExample to RKCatalog for testing. Needs to be updated with
support for using OAuth.
Cleaned up @rodchile's excellent work integration OAuth 1.0 and 2.0 into RestKit. Changes
are as follows:
* Introduced new RKRequestAuthenticationType to replace the forceBasicAuthentication and other
methods for influencing how authorization works.
* Moved TDOAuth code into Vendor/
* Renamed authorization code flow classes and delegate methods for clarity.
Since OM 2.0 connection of relationships happened during the object mapping operation
instead of aggregately at the end of the process. In this commit, we have introduced a lightweight
queue for deferring portions of the mapping operation until a larger aggregate mapping has completed.
The changes are as follows:
* Introduced RKMappingOperationQueue for queueing portions of mapping. This is a synchronous queue modeled off
of NSOperationQueue that does NOT use threading (for Core Data friendliness).
* RKObjectMappingOperation now has a RKMappingOperationQueue queue property that defaults to nil
* RKObjectMappingOperation instances built via RKObjectMapper will has a mapping operation queue
assigned to the property.
* If a queue is present, RKManagedObjectMappingOperation will use it to defer the connection of relationships.
* At the end of an RKObjectMapper process, the mapping operation queue used by all mapping operations created
during the process will be executed. This allows all relationships to be connected after all object creation
has completed.
The queue is general purpose, though currently only used for the connection of relationships.
Fix of RKObjectMappingOperation does not respect forceCollectionMapping (Issue #341) This fixes#341. A solid pull request with good tests. I ran through it prior to his new test coverage last night and it looked good with no discernible side-effects. With the new test coverage, the added code gets exercised appropriately.
The managedObjectContext helper method will now raise an exception if there is not a sharedManager or the current sharedManager does not have an objectStore configured.
The following changes were made:
* Added isCacheable to RKRequest
* Return nil for cacheKey on non-cacheable RKRequests
* Updated RKRequestCache to ensure attempts to cache uncacheable requests has no effect
* Added basic unit tests and expanded comments on some parts of the cache API
Didn't add header to NSManagedObject+ActiveRecord.h,
NSManagedObject+ActiveRecord.m and RKManagedObjectCache.h .
NSManagedObject+ActiveRecord was adapted from someone else, and
RKManagedObjectCache has different code formatting. Will update those
once I get confirmation on them.
