Setting retina build status image for travis ci

Yep :)
Merge pull request #90 from haaakon/patch-1

Setting retina build status image for travis ci
update changelog
README updates

Signed-off-by: Stephen Celis <stephen@stephencelis.com>
Update podspec for 1.5.0

Signed-off-by: Stephen Celis <stephen@stephencelis.com>
Remove/ignore Podfile.lock

While the lockfile is important for private apps, it gets in the way for
open source libraries. Bundler, for example, encourages gem builders to
_not_ check in the Gemfile.lock. We should adopt a similar practice.

Signed-off-by: Stephen Celis <stephen@stephencelis.com>
Chained fetch request builder (ObjectiveRelation)

This commit provides to ObjectiveRecord what Arel[1] provided to Active
Record.

[1]: https://github.com/rails/arel

It simplifies the interface by using a chained request builder. Instead
of:

  [Person where:@{@"firstName": @"Stephen"} order:@"lastName" limit:@5];

We can use:

  [[[Person where:@"firstName = %@", @"Stephen"] order:@"lastName"] limit:5];

Because of chaining, we can remove most of the methods that build
complex fetch requests all at once, and we can support features that
were previously omitted, like offset (perhaps due to the number of
method signature permutations required to make them work).

Even +countWhere: can be removed:

  [[Person where:@"firstName = %@", @"Stephen"] count];

Each step in the chain returns a lazy-loading fetch request. So you can
store a base request and build on it in different ways. E.g.,

  // Create 2 people in a private context
  id privatePeople = [Person inContext:privateContext];
  [privatePeople create:@{@"firstName": @"Marin"}];
  [privatePeople create:@{@"firstName": @"Stephen"}];

  // Pagination
  id page = [Person limit: 5];
  // ...
  page = [page offset:[page offset] + [page limit]];

A fetch request is not executed before you ask for data that would
require a fetch, e.g. by iterating, fetching a specific result, or a
count.

Fetch request builders conform to NSFastEnumeration and forward array
selectors to the result set, so act on them as you would act on the
final NSArray:

  for (Person *person in [Person all]) {
    // ...
  }

  [[Person where:@"admin = NO"] setValue:@YES forKey:@"admin"];

Signed-off-by: Stephen Celis <stephen@stephencelis.com>
Add updateAll:

Quickly allows records to be updated via scope.

Signed-off-by: Stephen Celis <stephen@stephencelis.com>
Reorganize ActiveRecord/Relation methods

Organize by:

 - Building fetch requests
 - Executing fetch requests
 - Inserting entities
 - Modifying entities
 - Deleting entities

Signed-off-by: Stephen Celis <stephen@stephencelis.com>
Expose .limit and .offset on ObjectiveRelation

Good for public introspection (for, e.g., pagination).

Signed-off-by: Stephen Celis <stephen@stephencelis.com>
Update ObjectiveRelation methods to be more descriptive

Entity is usually used to describe an NSEntityDescription, so let's use
ManagedObjectClass, instead.

Signed-off-by: Stephen Celis <stephen@stephencelis.com>
Relationship relation builders

Adds support for -[NSManagedObject relationWithName:], which returns an
ObjectiveRelation for to-many relationships that have an inverse
relationship that can be introspected.

These relations will forward selectors to the original (mutable) set
where applicable. E.g.,

  [[person relationWithName:@"employees"] addObject:employee];

If the dynamic property defined for one of these relationships is of
type id, it will return an ObjectiveRelation, instead:

  @interface Person : NSManagedObject
  @property (nonatomic, strong) id employees;
  @end

  @implementation Person
  @dynamic employees;
  @end

  Person *person = [Person find:@"firstName = %@", @"Stephen"];
  // Fetch through relationship
  [person.employees where:@"firstName = %@", @"Marin"];
  // Create through relationship
  [person.employees create:@{@"firstName": @"Dave"}];

Signed-off-by: Stephen Celis <stephen@stephencelis.com>
Consistency

This project appears to prefer listing properties in the following
order:

 - readonly/readwrite
 - assign/weak/strong/retain/copy
 - atomic/nonatomic

Signed-off-by: Stephen Celis <stephen@stephencelis.com>
Whitespace adjustments

Signed-off-by: Stephen Celis <stephen@stephencelis.com>
Expose .fetchedObjects on relations

Signed-off-by: Stephen Celis <stephen@stephencelis.com>
Consistency

Signed-off-by: Stephen Celis <stephen@stephencelis.com>
Prefer synthesis

Signed-off-by: Stephen Celis <stephen@stephencelis.com>
Expose fetchRequest (and fetchedResultsController)

In exposing NSFetchedResultsController we need to better manage the
library's iOS and OS X interface separation.

Signed-off-by: Stephen Celis <stephen@stephencelis.com>
Make ObjectiveRelation stronger

Caveats? This removes some (magic), id-based functionality, including:

 - Calling NSArray methods directly on ObjectiveRelation objects.

     // This
     [[Person all] map:^(Person *person) { /* ... */ }];
     // Becomes this
     [[Person all].fetchedObjects map:^(Person *person) { /* ... */ }];
     // But this is still fine (because of NSFastEnumeration)
     for (Person *person in [Person all]) { /* ... */ }

 - Calling NSMutableSet methods directly on ObjectiveRelation objects.

     // This no longer works
     [person.employees addObject:[Person create:@{@"firstName": @"Marin"}]];
     // But we have a better helper, so it's OK
     [person.employees create:@{@"firstName": @"Dave"}];

Other considerations include whether we want to expose ObjectiveRelation
objects directly, or an ObjectiveRelation protocol:

  // This
  ObjectiveRelation *record;
  // Or this
  id<ObjectiveRelation> relation;

They behave, basically, the same, as the ObjectiveRelation class is a
direct subclass of NSObject, and the ObjectiveRelation protocol would
enforce the same strict typing.

Signed-off-by: Stephen Celis <stephen@stephencelis.com>
Clean up tests

 - Remove header comments
 - Remove CoreData-generated relationship methods
 - Normalize formatting

Signed-off-by: Stephen Celis <stephen@stephencelis.com>