Better database??

David Relson relson at osagesoftware.com
Wed Mar 3 18:00:35 CET 2004


On Wed, 3 Mar 2004 17:13:15 +0100
Matthias Andree wrote:

> On Wed, 03 Mar 2004, michael at optusnet.com.au wrote:

...[snip]...

> Well, this looks like a layering violation. The datastore* files
> provide a data storage service to bogofilter and are at a lower level
> than bogofilter's special tokens such as ROBX are - these are in the
> application level and should not be known to datastore*.
> 
> If you think we need a data abstraction layer that exceeds "cleanup"
> or that crosses layering boundaries, please define the two interfaces
> and functionality the abstraction layer should provide and what the
> advantages are.

With our current design, there are two layers:

	datastore and database

The database layer exists in flavors for BerkeleyDB, tdb, qdbm, etc. All
it knows is attributes and values, where an attribute is a bogofilter
token and a value is a byte sequence (typically 4 bytes of spam count, 4
bytes of ham count, and (optionally) 4 bytes of timestamp).  Info is
communicated to it using "dbv_t *p" where "dbv" means "database value".

The datastore layer uses "dsv_t *p" (datastore values) for communication
with the higher level, i.e. bogofilter and bogoutil, and uses "dbv_t *"
when communicating with the lower level database layer.

Ideally dbv_t only appears in datastore.c, database_*.c, and the
corresponding .h files and dsv_t _never_ appears in a database_xyz file.
 There may well be an exception or two to these ideals, but I've not
checked.





More information about the Bogofilter mailing list