I think this should be defined along side the other keys in the MMRecord header.

However, I'm trying to think of an alternate way to implement this. We're essentially massaging response data into a more populate-able format. While a value transformer is one way to do that, it's not the only one. For example, We would probably never even need the reverseTransform functionality of a value transformer, because we would probably never be converting the data back into the format it was in originally. That means NSValueTransformer may not be the right tool for the job.

Are there some other ways we could implement this? An optional class method on MMRecord.h that would be called with the attribute and the value could be one. Or even with the entire dictionary of data for that record to give you a chance to modify all of it. It could also be a block that's specified somehow. Or it could be a custom marshaler that overrides populateProtoRecord:attributeDescription:fromDictionary and just performs the transformation there.

I'm hesitant to continue adding more userInfo dictionary keys to the configuration process. The goal of the original implementation of MMRecord's transformer support was just to support custom objects as transformable values. That may not have even been possible, since what you brought up is that Core Data's transformable attributes expect an NSData to be returned - not an NSCoding compatible class. That's why I mentioned the two goals. I think my original goal may not even have been relevant. And this goal, while still a very worthy and important one, does seem different.

What do you think about alternate methods of implementing this functionality?

Thanks,

- Conrad