The Object Database -------------------
The DB class coordinates the activities of multiple database Connection instances. Most of the work is done by the Connections created via the open method.
The DB instance manages a pool of connections. If a connection is closed, it is returned to the pool and its object cache is preserved. A subsequent call to open() will reuse the connection. There is no hard limit on the pool size. If more than `pool_size` connections are opened, a warning is logged, and if more than twice that many, a critical problem is logged.
The class variable klass
is used by open() to create database
connections. It is set to Connection, but a subclass could override
it to provide a different connection implementation.
:Cvariables: - `klass`: Class used by L{open} to create database connections
:Groups: - `User Methods`: __init__, open, close, undo, pack, classFactory - `Inspection Methods`: getName, getSize, objectCount, getActivityMonitor, setActivityMonitor - `Connection Pool Methods`: getPoolSize, getVersionPoolSize, removeVersionPool, setPoolSize, setVersionPoolSize - `Transaction Methods`: invalidate - `Other Methods`: lastTransaction, connectionDebugInfo - `Version Methods`: modifiedInVersion, abortVersion, commitVersion, versionEmpty - `Cache Inspection Methods`: cacheDetail, cacheExtremeDetail, cacheFullSweep, cacheLastGCTime, cacheMinimize, cacheSize, cacheDetailSize, getCacheSize, getVersionCacheSize, setCacheSize, setVersionCacheSize
klass
(type: type
)
<class 'ZODB.Connection.Connection'>
abortVersion(version, txn=None)
cacheDetail()
Return information on objects in the various caches
Organized by class.
cacheDetailSize()
cacheExtremeDetail()
cacheFullSweep()
cacheLastGCTime()
cacheMinimize()
cacheSize()
classFactory(connection, modulename, globalname)
close()
Close the database and its underlying storage.
It is important to close the database, because the storage may flush in-memory data structures to disk when it is closed. Leaving the storage open with the process exits can cause the next open to be slow.
What effect does closing the database have on existing connections? Technically, they remain open, but their storage is closed, so they stop behaving usefully. Perhaps close() should also close all the Connections.
commitVersion(source, destination='', txn=None)
connectionDebugInfo()
getActivityMonitor()
getCacheSize()
getName()
getPoolSize()
getSize()
getVersionCacheSize()
getVersionPoolSize()
invalidate(tid, oids, connection=None, version='')
Invalidate references to a given oid.
This is used to indicate that one of the connections has committed a change to the object. The connection commiting the change should be passed in to prevent useless (but harmless) messages to the connection.
invalidateCache()
Invalidate each of the connection caches
lastTransaction()
objectCount()
open(version='', transaction_manager=None)
Return a database Connection for use by application code.
The optional `version` argument can be used to specify that a version connection is desired.
Note that the connection pool is managed as a stack, to increase the likelihood that the connection's stack will include useful objects.
:Parameters: - `version`: the "version" that all changes will be made in, defaults to no version. - `transaction_manager`: transaction manager to use. None means use the default transaction manager.
pack(t=None, days=0)
Pack the storage, deleting unused object revisions.
A pack is always performed relative to a particular time, by default the current time. All object revisions that are not reachable as of the pack time are deleted from the storage.
The cost of this operation varies by storage, but it is usually an expensive operation.
There are two optional arguments that can be used to set the pack time: t, pack time in seconds since the epcoh, and days, the number of days to subtract from t or from the current time if t is not specified.
removeVersionPool(version)
setActivityMonitor(am)
setCacheSize(size)
setPoolSize(size)
setVersionCacheSize(size)
setVersionPoolSize(size)
undo(id, txn=None)
Undo a transaction identified by id.
A transaction can be undone if all of the objects involved in the transaction were not modified subsequently, if any modifications can be resolved by conflict resolution, or if subsequent changes resulted in the same object state.
The value of id should be generated by calling undoLog() or undoInfo(). The value of id is not the same as a transaction id used by other methods; it is unique to undo().
:Parameters: - `id`: a storage-specific transaction identifier - `txn`: transaction context to use for undo(). By default, uses the current transaction.
There are no known subclasses.