How to deal with mixed relationships?

[sarbogast]

My API endpoint is returning instances of IPConversationEntity, but each IPConversationEntity has several participants, and participants can be instances of one of several classes. Is there a way to deal with that sort of mixed-type one-to-many relationship in Core Data that MMRecord can handle?

[cnstoll]

If the entities can all be sub-entities of the same parent, then you can use the MMRecord mechanism for returning a desired type of sub entity for a given object.

/**
This method can be implemented to determine if a sub entity record class should be used to
represent the data for a particular record. The dictionary representation of the record is passed
as a parameter, and the implementation should return YES or NO if that dictionary is a valid
representation for a record of this type. This method is NOT intended to be used for validation,
but for population when a record class has sub entities associated with it's entity description.
The typical use case would be for when you are requesting records of a given class, but depending
on the response values, some (or all) of the records contained in the response should result in a
sub entity record type being created or updated.

@param dict The dictionary representation of a record.
@return YES if the dictionary represents a record of this type, NO otherwise.
@discussion This method will be called when startRequestForURN is called on a MMRecord class whose
entity description contains sub entities. This method will be called on each of those in no
particular order and will use the class for the first record class that returns YES. If no record
classes return YES, the called MMRecord class will be used.
*/

• (BOOL)shouldUseSubEntityRecordClassToRepresentData:(NSDictionary *)dict;

[cnstoll]

Alternatively, you can also subclass the representation and marshaller to provide custom behavior similar to what you are describing.

[sarbogast]

The first approach would work but I have another issue: #67

[sarbogast]

As a matter of fact, implementing shouldUseSubEntityRecordClassToRepresentData doesn't seem to work. I set up a breakpoint in it for all 3 subclasses and it is never called.
IPConversationEntity has a participants relationship that is a set of IPParticipantEntity. IPParticipantEntity is a superclass for IPUserEntity, IPBusinessEntity and IPInvitedUserEntity. All of those 3 subclasses have an implementation of +(BOOL)shouldUseSubEntityRecordClassToRepresentData but it is never called. So all elements in conversation.participants are simply instances of IPParticipantEntity.

[sarbogast]

I just found this issue: #52
That seems to indicate that subclassing on relationship entities is not supported yet in 1.3.0. Am I correct?

[cnstoll]

Doh! Yep, that is most likely the case. Do you want to manually pull in the latest and see if that works for you? I need to release the new version soon, but there were a few things I wanted to do first.

[sarbogast]

I just did, and it works. Thanks

[sarbogast]

I have another case where the subclassing technique won't work because one of the classes is already a subentity of another. Could you elaborate on "Alternatively, you can also subclass the representation and marshaller to provide custom behavior similar to what you are describing." How could I do that?

[cnstoll]

MMRecordMarshaller and MMRecordRepresentation are the two classes response for a) applying values to the managed objects and b) deciding how a dictionary and its contained values get parsed and populated on a managed object. There's subclassing notes on those classes. Subclassing those classes will let you customize almost anything about how a request's response gets handled. There are of course some limitations, but its pretty flexible. That may or may not work for your case.