[bind10-dev] writable datasources 3/3; API proposal
Jelte Jansen
jelte at isc.org
Mon May 10 08:44:34 UTC 2010
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
(to be added to data_source.h)
//
// Writable data sources
//
// To implement a new writable data source, subclass and overwrite
// the 'low-level' methods. Overriding the high-level ones is
// optional
//
//
// low-level methods.
//
/**
* Add an RRset to a zone. If the RRset already exists, the
* RRs in this set are added to it.
*/
virtual Result addRRset(isc::dns::Name* zonename, isc::dns::RRset&
rrset) = 0;
/**
* Delete an RRset from a zone. If the RRset in the zone contains
* more RRs than the given one here, keep those.
*/
virtual Result deleteRRset(isc::dns::Name* zonename,
isc::dns::RRset& rrset) = 0;
/**
* Returns if we have the zone and the serial number we pass is
* higher than the serial number in the SOA record of the given
* zone (according to serial arithmetic). Returns false otherwise.
* (TODO: this one perhaps does not need to be overwritten as it
* can use existing functions)
*/
virtual bool checkSerial(isc::dns::Name* zonename, uint32_t serial) = 0;
/**
* Lock a zone (or database, or rrset(?). This should lock the
* underlying backend, not this instance...
*/
virtual void getWriteLock();
virtual void releaseWriteLock();
/**
* Start a transaction. If the backend supports transactions,
* this is just a wrapper. If not, you can either fake transactions
* (by making this a nop), and risk data inconsistency, or
* implement some form of transactions yourself.
* One way to do it (if there are no threads) is to make addRRset
* and deleteRRset so that their behaviour changes if one is 'in'
* a transaction (by checking and storing, locking the database upon
* commit and then performing all stored actions).
* (TODO: perhaps we could also proved some basic defaults for
* these, though i'm not sure)
* start should probably error if there already is a transaction
* running (or lock, the point here is to do batch commits, not
* concurrency, at this level).
*/
virtual void startTransaction() = 0;
virtual void commitTransaction() = 0;
virtual void rollbackTransaction() = 0;
/**
* Returns true if all the RRs in the given rrset are in the zone.
* If rdatalen == 0, this will return true if there is an rrset with
* the same name, class and type, regardless of the number and data
* of the rrs it contains.
*/
virtual bool containsRRset(isc::dns::Name* zonename,
isc::dns::RRset& rrset) = 0;
/**
* Returns true if non of the RRs in the given rrset are in the
* zone.
* Note that this does not mean *other* rrs can't be present with
* the same name, class and type, unless one of the RRs in this set
* has rdatalen=0;
*/
virtual bool doesNotContainRRset(isc::dns::Name* zonename,
isc::dns::RRset& rrset) = 0;
//
// High-level functions
//
// These do not need to be overwritten by subclasses, but they
// may be if there is a more efficient way to handle them
// than the defaults.
//
/**
* Drop all records for the given zone, and add all records in
* the given RRsetList
* (for use in loadzone and axfr)
* TODO: what to do with loadzone for a zone that is not in any
* data source yet? We need a way to specify where to store it...
* (probably so that if none is given, the first writable data
* source is used)
*/
// TODO: in theory this one could be replaced by a deleteAllRRsets
// function, together with replaceRRsets below. However, that
// would probably mean we have to unlock and relock the database,
// or not do transactions from within these functions (but start
// and commit/rollback at the caller, which i think is counter-
// intuitive
virtual Result replaceZone(isc::dns::Name* zonename, RRSetList rrsets);
/**
* Deletes a set of RRsets, and adds another one
* (for use in IXFR)
*/
virtual Result replaceRRsets(isc::dns::Name* zonename, RRSetList
delete, RRSetList add);
/**
* Full handler for IXFR message.
*/
virtual Result doIXFR(isc::dns::Message *msg);
/**
* Full handler for dynamic update message
*/
virtual Result doUpdate(isc::dns::Message *msg);
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkvnx3IACgkQ4nZCKsdOncXKTgCeMkniPutfwFQwAVq+AhYzHHlT
JFoAn3xeyw58eUFPkqhwf1WeX2m9ytYn
=rZtv
-----END PGP SIGNATURE-----
More information about the bind10-dev
mailing list