To me, the bottom line is that (ideology aside) I seem to need to treat
Metakit storages and views differently than I treat other "normal" Python
objects. And I need to take special care in handling these [...]
It does not really help to re-iterate the same over and over again :(
I never encounter this issue. All application scenarios I use have a clear model of when data from a storage on file is and is not in use. Keeping lots of storages open sounds a bit unusual to me - like a database of databases.
You've been given reasons, and workarounds.
Compare this to, for example, BSDDB.
You can't. The issue is derived views, and views not holding on to their storage. It's not a BSDDB vs. MK issue, it's about views, which are not limited to data in MK files.
As I said, I'm willing to deal with this and make changes. But I think it would be best for all of us to keep trying to make progress towards that goal - instead of all going for the trenches and digging in.
At the C++ level, I don't think a reference to the storage can be added to each view attached to (i.e. produced from) it - it creates a cycle (in C++, not Python). So that options is out, AFAICT.
What other options are there?
-jcw
_______________________________________________ metakit mailing list - [EMAIL PROTECTED] http://www.equi4.com/mailman/listinfo/metakit
