Can I use multiple values for a rollup key on the same Endeca record?

Question

We have a business need to to aggregate our records using different criteria, based on user navigation. We are thinking of using a rollup key with multiple values to help with the aggregation, but we are running into some issues.
Here is a made-up xample of what we want to do: assume we have a group of products and these products can be organized into groups using parent-child relationships. We would like to create an aggregate record for each parent, and we want the aggregate record for each parent to include all the children for the parent. To achieve this, we use a field called "parent_rec_spec" that holds the parent record spec and we set the same value on the field for the parent and its children. When we do rollup using the parent_rec_spec as the rollup key, we are able to see one aggregate record for each parent (with its children).
The previous setup worked perfectly for us so far. But now we are getting a business requirement that allows children nodes to be linked to multiple parents at the same time. We were hoping of using another dimension to limit the records based on user roles/characteristics , so that only applicable parents/children are displayed (for example, we can use "market" as an additional filtering property, and we decide to show all parents/children for "North America", while hiding the parents/children for other markets).
This caused an odd behavior when children are linked to multiple parents. For example, assume that SKUs A and B were linked to parents in "North America" and "Europe" at the same time, and assume that the user chose the "North America" market. The navigation state would eliminate the parents/children that are no in North America, and will also cause the parents/children that are labeled for North America to show up and be aggregated correctly. This however will lead to the creation of additional aggregate records for the A and B using the parent_rec_spec values that would have linked them to the Europe parents (even though the parents are hidden away).
Here is an example index file that we used to load the test data:
Update||1
Market||North America
Record Type||Product
Name||Parent 1
rec_spec||P1
parent_rec_spec||P1
EOR
Update||1
Market||Europe
Record Type||Product
Name||Parent 2
rec_spec||P2
parent_rec_spec||P2
EOR
Update||1
Market||North America
Record Type||Product
Name||Child A
rec_spec||A
parent_rec_spec||P1
EOR
Update||1
Market||North America
Market||Europe
Record Type||Product
Name||Child B
rec_spec||B
parent_rec_spec||P1
parent_rec_spec||P2
EOR
Update||1
Market||North America
Market||Europe
Record Type||Product
Name||Child C
rec_spec||C
parent_rec_spec||P1
parent_rec_spec||P2
EOR
Update||1
Market||Europe
Record Type||Product
Name||Child D
rec_spec||D
parent_rec_spec||P2
EOR
In this setup, we have parent P1 marked for North America with children A, B and C, and parent P2 marked for Europe with B, C and D as children. When we use North America as a filter in the navigation state, and parent_rec_spec as the rollup key, then we will see an aggregate record for P1, A, B and C. But we will also see an aggregate record for B and C by itself (presumably because of the other parent_rec_spec value on these records).
The actual data that we are testing with is more complicated, but the end result is similar. We also noticed that the additional aggregate records would not be created always, depending on the ordering of the records.
The question that I need help with is this: is there a way to fine tune the rollup logic so that it can only include certain records (in the example above, we can change the rec_spec from PA and PB to PA_North_America and PB_Europe and then we would be interested in rolling up using values that end with NorthAmerica).
By the way, we considered using separate rollup keys for each context (like parent_rec_spec_north_america and parent_rec_spec_europe), but the number of contexts is dynamic, and might grow large. So it is not easy for us to create the additional properties on the fly, and we are concerned about the possible large number of dimensions.

Answer 1

http://www.adobe.com/cfusion/webforums/forum/messageview.cfm?catid=2&threadid=1157850