Wrestling with RAM relationships

Hi Des

Thanks for the feedback in your blog post. Have you used range relationships in the past? In the current version of RAM you can create a relationship to another asset with a rule such as 'Relate to the highest version of asset B where the version of asset B is 2.0 or less.' What if RAM added a feature where when you submitted asset A you could add a relationship to asset B where the rule was 'Relate to the highest version of asset B where the version of asset B is equal to or less than the version of asset A'?

So, in your example you would submit asset Acme 1.0 with relationships to assets Foo 1.0 and Bar 1.0. For each relationship you add a range rule that says 'Relate to the highest version of asset Foo and asset Bar where the version is equal to or less than the version of asset Acme. Now, when you create asset Acme 2.0 the relationships to Foo 1.0 and Bar 1.0 are copied over. When you create Bar 2.0, the rule kicks in and the relationship between Bar 1.0 and Acme 2.0 is dropped and Acme 2.0 is now automatically related to Bar 2.0. A relationship between Bar 2.0 and Acme 1.0 is never created because it does not meet the rule you defined in your relationship.

I think this enhancement would solve your example because of the way you setup your versions, but I'm not sure that it would solve all of your use cases.

Your suggestion might address this specific example but the underlying problem remains. It seems that the root problem is that we carry over relationships regardless of which asset was the source of the relationship. We have this problem with our assets. For example:

Asset - version - type
RAM Server Implementation - 7.2 - Implementation
JSF Widget Library - 3.1.7 - Software
JSF Widget Library - 3.1.10 - Software

Use case:

JSF Widget Library 3.1.7 is in the repository
We create RAM Server Implementation 7.2 and add a dependency relationship on JSF Widget Library 3.1.7
The JWL team comes along and create the 3.1.10 version of JSF Widget Library.

In this scenario, when the new version is created, all of the relationships on JSF Widget Library 3.1.7 are carried over to 3.1.10. So it makes a dependency relationship on RAM Server Implementation 7.2 even though that asset is not dependent on the 3.1.10 version.

Possible solution: If RAM knew that RAM Server Implementation 7.2 "owned" the relationship on JSF Widget Library 3.1.7 (and therefore the widget library asset does not own the relationship) and if RAM only copied over relationships than an asset owns when creating a new version, it would may solve the more general problem.

Thanks for the comments guys. I'm going to have a stab at a solution as well.

Basically the example I gave shows that we are creating new Assets within the context of them having a particluar parent. For example when I create a new BAR version 2.0 I am creating it within the context of belonging to ACME 2.0. Therefore I think an easy solution would be to have a new version button to the right of the relationship to that Asset within the parent Assets general details page. So not only could you create a new version of the parent Asset on it's page you could also create new versions of the related Assets from its page. Creating a new version of a related Asset this way would be a special case. The special case would be as follows:

1. A new version of the related Asset is created;
2. Any relationships that the new version of the related Asset had to previous versions of the parent Asset are dropped;
3. The previous version of the related Asset should have any relationship it has to the parent removed.

This is a general solution that would solve our particular use case and also anyone else's that wanted to do something similiar. Also, the RAM Client API could be extended to have similar functionality.

What do you reckon? Any downsides to this approach?

@Matt I like the ownership concept and think it's powerful. My one concern is that when I define a relationship between two assets there is not always a clear owner. If the owner concept is introduced in RAM I think it should be optional.

@Des I like your idea because of its simplicity. I don't see any major downsides to this approach. I think it could be a bit confusing to users who may want/expect the parent asset to be related to both versions of the related asset, but this is probably a more unusual scenario and the functionality you describe could be made clear through UI. We will definitely consider this idea for a future version of RAM.

If you generalize this.... really what we are saying is that there is a "graph" of assets ... and you want to create a "new version of the graph" that will contain a combination of new assets, as well as the existing assets (from the previous graph version).


We need to look at this as a configuration management http://en.wikipedia.org/wiki/Configuration_management#Software_configuration_management where we provide means to manage the collection of the assets in the graph.