On Sat, Sep 27, 2003 at 11:17:46PM +0200, "Martin v. L?wis" wrote: > Gregory P. Smith wrote: > > >It is worth noting that using a DBEnv in this manner will create a bunch > >of auxilary DBEnv related files on the disk. That has the potential of > >confusing people who expect only the database file. It also means that > >separate unrelated databases cannot exist in the same directory without > >being part of the same DBEnv (which BerkeleyDB multiprocess access should > >handle just fine; but it might not be what people expect). > > I see. I could accept that it is confusing; would it also be backwards > compatible (i.e. would BerkeleyDB create those files on demand, and > would old Python installation still be able to read the database even > if those files where around)? It would not. Its already not backwards compatible. Thats what the bsddb185 module is for. The BerkeleyDB file format changed between 3.1, 3.2 and 4.0 even. BerkeleyDB can upgrade from an older format to the current one (using the DB.upgrade method). > >An alternative would be to say that applications that want to use bsddb > >with threading need to use the *real* BerkeleyDB API rather than the > >ancient compatibility interface. (it'd be easy to check that bsddb > >doesn't get used by multiple threads, raising an exception if it does) > > But is it also easy to detect that multiple applications try to use > the same database? No. But it is easy to document. The old bsddb module never allowed it either. I only suggest detecting multithreaded access because it is possible to do. Anyone who wants multiprocess access should use the real DBEnv+DB interface and know what they're doing. -g
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4