But I would prefer a situation that is uniform,Sure bsddb has "surprises" and they are *exactly* the same as metakit.
predictable and can be documented so that the average programmer who just
wants to use Metakit (rather than understand its implementation details)
can use it with confidence and without surprises. Compare this to, for
example, BSDDB. In many ways Metakit is much easier to use that BSDDB, but
BSDDB does not seem to have such surprises.
import bsddb
h = bsddb.hashopen("foo")
h["key1"] = "value1"
cursor = h.db.cursor()
del h
cursor.next()
# = big fat crash.There is nothing in the bsddb docs that says you *can't* do this. The bsddb wrapper supplies nice functions so you can iterate through the database using
h.next() h.prev()
but this means that you can only have one cursor at a time.
I understand your feelings on the subject, but there are two issues:
1) fast database access using a minimal database interface
2) pythonic control over the database with (slightly) more memory overhead and some (slight) speed loss.
I have done both but it seems that the following *fix* to metakit.py should solve your pressing issues. It adds a close method to metakit.storage and keeps the storage alive until the end of the program execution or until storage.close() is called. I used the global NEXTID as opposed to an idgenerator to be compatible with python 1.5 through the present. Add this to the top of your metakit.py file
--snip--
# both mk.py and Mk4py.{dll,so} can be found by Python.
from Mk4py import storage
_storage = storage
from Mk4py import *
import string
__storages__ = {}
NEXTID = 1class storage: def __init__(self, *a, **kw): global NEXTID self._st = apply(_storage, a, kw) self._id = NEXTID NEXTID = NEXTID + 1 __storages__[NEXTID] = self
def __getattr__(self, attribute):
if not self._st:
raise IOError("The storage has been closed")
return getattr(self._st, attribute)def close(self): self._st = None del __storages__[self._id]
---end---
Usage example.
>>> st = metakit.storage()
>>> vw = st.getas("test[a,b,c]")
>>> vw.append("abc")
0
>>> metakit.dump(vw)
a b c
- - -
a b c
- - -
Total: 1 rows
>>> st.close()
>>> metakit.dump(vw)Total: 1 rows
Of course, the views are not aware that the storage has been closed:
>>> st = metakit.storage()
>>> vw = st.getas("test[a,b,c]")
>>> vw.append("abc")
0
>>> metakit.dump(vw)
a b c
- - -
a b c
- - -
Total: 1 rows
>>> st.close()
>>> metakit.dump(vw)We could solve this at the cost of a lot more error checking. Essentially, *every* operation on a view will have to check the parent storage to see if it is still open. If this is something you would like, I have a skeleton proxy for storages and views we could make into a more pythonic metakit wrapper. If you are willing to betatest and provide input, I'll be happy to finish it and submit it to J.C. as an alternative metakit wrapper in *addition* to the current one, not as a replacement. It will be 100% compatible with the current interface though.
Brian
Total: 1 rows
_______________________________________________ metakit mailing list - [EMAIL PROTECTED] http://www.equi4.com/mailman/listinfo/metakit
