s/mneorr.com/supermar.in
update objectivesugar
Check existence of attribute/relationship by name before setting value by key
Merge pull request #67 from kattrali/ignore-unknown-keys

Ignore unknown keys
Handle mapping transformations in one place

This pushes most of the transformation logic back into the Mappings
category, and centralizes where properties are filtered in the
ActiveRecord category.

Because of this, we can ensure that:

 - transformations happen before KVC methods like willChangeValueForKey:
   and didChangeValueForKey: are called, and

 - invalid keys are dropped before building a predicate for fetching via
   findOrCreate:.

Reported-by: amseddi
Signed-off-by: Stephen Celis <stephen@stephencelis.com>
Merge pull request #87 from supermarin/mappings-filter

Handle mapping transformations in one place
Add test
Merge pull request #62 from kattrali/recursive-find-create

Add tests for recursively creating models using findOrCreate:
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>