If you've been working with related items, you may have found that it's a bit inconvenient to use right now. Specifically:
We're having some discussions around how to fix the first one, and, if possible, the other two as well. We had originally thought that we would simply modify the platform NewItems() call to have a way to say "link all of these together using related items", but it turns out that there's no simple way to do that, and the complex ways have architectural implications we don't like.
So, we're considering a different scheme. In this scheme, rather than linking together using the platform-generated key (ie CommonData.Key.Id), we would link together using an application-generated client-id instead. So, to link two items together, you would do the following:
We would likely provide a helper function to do #3 - #6, so you could merely write "MakeThingsRelated(a, b)", and the helper would do all the work of generating the client ids and hooking them up.
We would also modify "GetItem" to retrieve an object either using the Key.Id or the Client id, and the code you would write to fetch the related items would be the same as what you currently write.
There are three disadvantages to this approach that we see:
We could avoid #2 and #3 by adding a new method to fetch an item by clientId (ie GetItemByClientId()). That would make that api clearer, but would have the unfortunate byproduct of requiring a rewrite of all existing code that uses related items to be able to deal with client-related items (it would need to know whether to call GetItem() or GetItemByClientId()...).
We're leaning towards doing the client-id approach, but would like any thoughts you might have.