Relational member data

[codygustafson]

I would like to start a conversation around the data dictionary Member information. In our database we store emails (as well as other information) as a "has many" relationship. I thought it would be good to start with one example, "emails" has the following fields.

• pkey
• member_key
• name
• type
• address
• is_primary
• is_display
• is_verified

Using the data dictionary, we can only export this as MemberEmail, which has mostly worked for exporting this data to third parties. But note that I can only export a single email's address, so some data is missing. The next problem comes up when we talk about writing data back into the MLS. We obviously cannot support writes using this field as an interface. We need either a complex type with all my fields or a separate entity type.

Should we be talking with data dictionary to make a new type or is there a way we can handle this within transport? I would like some discussion on how I can proceed with presenting all available information. This same problem exists for addresses, phone numbers, websites, and likely more.

[codygustafson]

@darnjo, is this something I should start in Data Dictionary with?

[darnjo]

Good question. So, if I'm understanding this correctly, you would want a way to provide multiple email addresses for a given Member record. Currently, Member only has MemberEmail, so you can only transport the primary. To address this, you'd like to have a collection of emails, either ComplexType or Resource expansions.

We don't have ComplexTypes in Transport at the moment, just expansions. That being said, this might be a good use for them. We would need to add a representation for them in the DD 1.7+ specification and Wiki (which I think is doable) and need to add something to our testing tools to support them. That said, I think it's reasonable that we might have a structured data set without a corresponding resource or even a key in some cases.

If we wanted to add it as an expansion, then this would go to the Data Dictionary. If we want to add it as a ComplexType then it would go to Transport after DD.

[codygustafson]

You are understanding correctly. I would prefer a ComplexType since this data will typically be required in the payload and I don't think an expansion is necessary. I'll work up a post for Data Dictionary. Thank you!

[darnjo]

No problem. Thanks for the post. We can circle back to this when we discuss Complex Types.