« Return to Thread: List construction for 'pivoting' list data
--------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@... For additional commands, e-mail: users-help@...Hi all-If anyone has any thoughts on this challenge, please share.We have a list of data objects that themselves contain lists of keys. We need to transform this list into another list of lists, but grouped by each key value (note that a single Data object is associated with a given key only once, but could be associated with multiple keysTo make this concrete, here's the source list:EventList<Data> allData = {OBJ1+{ABC, DEF, GHI},OBJ2+{ABC, GHI},OBJ3+{DEF}}and here's the desired result list:EventList<Data> dataForKeys={ABC+{OBJ1, OBJ2},DEF+{OBJ1, OBJ3},GHI+{OBJ1, OBJ2}}We will probably have 500-2000 data objects, and 500-1500 different keys. Each data object will probably have between 1 and 3 keys associated with it, although it could be as high as 500 in some instances.So far, I've come up with two approaches:Approach 1:Use a CollectionList against allData to get the list of keys, then apply UniqueList to get individual keys. Then apply a FunctionList against the list of keys that creates a FilterList for each key (filtering allData by the key passed into the Function). This approach has two issues (that I see, anyway) - first, there is an odd dependency in here that will probably require a related subject or listener to be registered with the publisher. I haven't tracked this down yet (if anyone has any quick pointers, I'd appreciate it) The test harness I put together yeterday evening definitely has problems with the order that list updates occur. The bigger problem that I see with this approach is that we could wind up with a whole lot of FilterLists that are filtering down to a very small sub-set of the original data set. Many of the FilterLists will be returning just a single element. The thought of having 500 filters lists all running at the same time gives me an uncomfortable feeling (but maybe I'm concerned over nothing?)Approach 2:Some sort of map based approach. For this to work, I'd need to have a multi-map implementation that would allow for a list of keys to be specified (instead of a single key). And that list would have to be an EventList. Then the list returned from the multi-map would also have to be an eventlist. The issue with this approach is that it's not even remotely close to practical given the current GL implementations. I could see trying to exapand the GL map wrapper so that it returns live lists (I think the obstacle here is that delete operations from the source list do not contain the deleted element, so it could be a right bugger to figure out how to remove elements from the mapped lists). Support for multi-keys would also require information about the removed element. If this approach were possible, I think that it would certainly be performant.Are there other approaches that may be better (or just different) than these two?Thanks in advance,- Kevin
« Return to Thread: List construction for 'pivoting' list data
| Free embeddable forum powered by Nabble | Forum Help |