I have a data structure (that works well so far) with three similar sub-views that are accessed, set, and summarized at different points. Now I have a requirement to output a summary of all the detail with a label that identifies with of the three sets the data came from. The solution I came up with doesn't work, so I am thinking out loud to see if someone has an idea that involves the least amount of re-coding. The sub-views are accessed quite a bit in normal processing, and the summary only needs to be created once or twice a month.
Simplized data format:db.getas('main[id:I,fname:S,lname:S,new[key:S,val:I],old[key:S,val: I],adj[key:S,val:I]')vw =jdb.dump(vw)id fname lname new old adjs ---- ------ ----- ------ ------ ------ 1 first1 last1 0 rows 0 rows 0 rows 2 bob last2 2 rows 0 rows 0 rows 4 first4 last4 2 rows 0 rows 4 rows
Using a combination of flatten, union, and project I can get REAL CLOSE to what I want:
jdb.dump(vw31)id key val ---- ----- --- 2 val10 10 2 val20 20 4 val10 10 4 val10 10 4 val20 20 4 val20 20 4 val30 30 4 val40 40
What I need is to know WHICH type of value each row is: id key val type ---- ----- --- ---- 2 val10 10 new 2 val20 20 new 4 val10 10 new 4 val10 10 adj 4 val20 20 new 4 val20 20 adj 4 val30 30 adj 4 val40 40 adj
The main problem being that one cannot successfully add a property to a
PyROViewer object, which is the result of the union and flatten
methods. It seems I either have to:
1) create a separate temporary view for each type and manually copy the flattened view into it, creating and setting 'type' appropriately. Then union off of these PyView objects. 2) or modify my system to always write the subview type into the subview. This means extra programming and run-time overhead, and extra strings in tens of thousands of records. 3) or some other creative idea you suggest.
This is exactly the sort of manipulation I hope to improve further, btw. It's becoming more and more clear that MK needs to offer full relational algebra + set operators.
First of all, note that you can add properties on the fly to views, they will stay around until commit/rollback/close (but won't be saved if they are not part of a getas).
So you could do:
- for each row in "new" subview:
set type property to "new"
- etc for other subviews
Then you'd be able to see ... ah, wait - I see your point now: Mk4py tracks R/O view status and forbids this (even though the C++ core would allow it).
Ok, another idea: create a view with N copies of the string "new" (can be done virtually with wrap() in Mk4py). Use pair() to add that view "next" to the subview, i.e. horizontal concatenation. Does that take you closer to a solution?
-jcw
_____________________________________________ Metakit mailing list - [EMAIL PROTECTED] http://www.equi4.com/mailman/listinfo/metakit
