Skip to content
This repository has been archived by the owner on Sep 12, 2018. It is now read-only.

Rethink mappings #88

Open
stephencelis opened this issue Mar 27, 2014 · 4 comments
Open

Rethink mappings #88

stephencelis opened this issue Mar 27, 2014 · 4 comments
Milestone

Comments

@stephencelis
Copy link
Collaborator

I see a few issues with the way mappings are currently implemented:

  1. They are automatically, categorically added to all NSManagedObject classes.
  2. They are coupled to the NSManagedObject+ActiveRecord category.
  3. They are unidirectional (there's no way to cast local properties back into remote ones).
  4. They are declarative (and with @kattrali's Support generic value transformation in mappings #66, the dictionary can become quickly bloated).
  5. They do a lot by default (auto-camelizing, for example).
  6. They are a memory leak (we cache every unique remote key that we check for).

Let's explore ways to address these issues.

Proposal 1: Protocol-based Mappings

One thought is that we could provide a protocol, like NSCoding, that could be used to serialize/deserialize these mappings. E.g.,

@protocol ORCoding <NSObject>
+ (NSDictionary *)dictionaryFromRemoteDictionary:(NSDictionary)dict;
- (NSDictionary *)remoteDictionaryRepresentation;
@end
  1. One would have to manually opt-in to the protocol.
  2. Looser coupling, using conformsToProtocol:.
  3. It would enforce bidirectional mappings.
  4. Method logic is more imperative.
  5. It's not included by default, so there are no defaults.
  6. No memory leaks (that are our fault, anyway)!
@stephencelis
Copy link
Collaborator Author

Relates to #68.

@stephencelis stephencelis added this to the 2.0 milestone Mar 27, 2014
@stephencelis
Copy link
Collaborator Author

/cc @supermarin

@dzenbot
Copy link

dzenbot commented Jun 6, 2014

+1
That approach looks really nice

@supermarin
Copy link
Owner

@stephencelis I think that makes sense

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants