My guess is the storage is going out of scope and being garbage collected and thereby closing your views without you knowing about it. You should keep the storage object in scope for your entire application run.
Here is some proof of this:
>>> storage = metakit.storage() >>> vw = storage.getas("test[I:I]") >>> vw.append(1) 0 >>> del storage >>> len(vw) 1 >>> vw[0].I Traceback (most recent call last): File "<stdin>", line 1, in ? AttributeError: I >>>
I'm of two minds whether I think this is a bug or not. I think it might be onerous for the python wrapper to keep track of all the views/subviews and like being created and used.
Spot on, I think.
When a storage goes out of scope, all data becomes unavailable. Keep in mind that MK uses memory-mapped files usually, so access to data actually goes *straight* to disk in most cases. Closing the file blocks off that access.
But MK does not control where view objects are used, it merely tracks reference counts (in the same way as Python does for its own PyObject's). The C++ view objects themselves are not tracked or reachable from the storage object.
So at some point, the only way out I could think of is to make views act as being empty. All "rows" continue to exist, they just don't have any properties anymore. Which does indeed make them pretty useless, but at least it leads to well-defined semantics.
Views which do come from a storage are "unattached" views, these are therefore autonomous. That's what you get when you use copies. The flip side is that they eat up memory, and have to be allocated and copied in full.
The way to avoid problems in Python, is to store the storage object in a variable which is guaranteed to stay around as long as its data needs to be accessed.
-jcw
_______________________________________________ metakit mailing list - [EMAIL PROTECTED] http://www.equi4.com/mailman/listinfo/metakit
