I have noticed this a while back on a very complicated nested subview operation.
Here is the solution I came up with.
Joins can be an expensive pain in SQL but you can mitigate them
tremendously in metakit. If you have relatively static data (i.e. a
row isn't deleted that often) here is what you can do. I'll give the
example on a two subview basis, but you can figure out the rest
mainview[index:I,...data...]
subview1[...subview...data]
subview2[...subview...data]
for row in mainview:
subviewdata1 = subview1[row.index]
subviewdata2 = subview2[row.index]
Essentially, as long as you can synchronize the mainview index with
the subview indices, joins are really not a pain at all.
I have the limiting assumption that subview rows can never be deleted
(they can be emptied though by nulling out the row which can save some
space)
When you add a row to the main view, the procedure is
index = len(subview1)
mainview.append({"index":index...})
# make sure that you append data to all the subviews to their sizes
# stay the same.
for view in subviews:
views.append(data)
This will be relatively easy to maintain and won't have the problem
with so many pointers to subviews.
Sorry this isn't a subview type organization, but I think that subview
overhead can be quite large. I have an example somewhere of a pretty
simple subview that eats up memory as well.
Brian
_____________________________________________
Metakit mailing list - [email protected]
http://www.equi4.com/mailman/listinfo/metakit
