Filed as a separate issue as per this comment on #1248916: [re|ab]use nonbinary directional relations for 1:n.
Use case: media playlists. A particular track can appear in more than one playlist but would not have a universal weight that dictated its order in each playlist. The 'weight' of a media item in a given playlist is a direct attribute of its relationship to (membership of) the playlist and so that value ought to be stored within the relationship, not the media item node, nor the playlist node.
davidwatson has expressed doubts that I also had about using the value of r_index for this purpose. In the proposal for 1:n described in the above issue, r_index 0 would designate the source and any other value of r_index would mean that the linked-to entity is a target (in a directional relationship). It does indeed seem cleaner to use a separate method to track ordering/weighting of items within a relationship. But that on the other hand means more work!
Comments
Comment #1
alexiswatson commentedAhh, I see what you're driving at now. Thanks for the clarification!
Given this use case, I'm honestly not sure where to put that information. I do agree for certain that this information shouldn't be stored as part of the parent or child nodes either way, because it has no meaning outside of the context of the relation and isn't necessarily global. r_index does seem the easiest way to do this, but I can't help but wonder if there's a cleaner way.
In any event, it seems like #1248916: [re|ab]use nonbinary directional relations for 1:n needs to be tackled first, wouldn't it?
Comment #2
martin_qYes to all of the above!
Comment #3
alexiswatson commentedMarking as postponed, then, at least until we nail nonbinary directional relations. :]
Comment #4
naught101 commentedThis issue is directionality agnostic
#1304196: How should we do weighted Relations?