RE: [srvx-devel] draft: srvx-2.0 database abstraction interface

[Zoot <zo...@ga...>]

> Feedback, if you have any :)
Just the thing I like to dispense on a Saturday night!

> Database Model
> --------------
> 
> The top level of the database consists of tables.  These are named
> mappings of keys to rows.  Each row has one primary key column, other
> columns, and child tables.  A column has a name, and data of one of
> several types:
>   - unsigned integer
>   - datetime
>   - string
>   - string list
>   - child table (of a specific type)
A signed integer type as well as the ability to implement loading and
storing of new types (for example, bit vectors) would be nice, but not
essential.

> Within a given table, each column contains the same type of data in
> all rows (the special value 'null' may exist in any column except the
> primary key column; whether it occurs, and the meaning if it does, is
> table-specific).
It may be useful to allow schemas to specify that a column is 'not
null,' as in SQL.

> A child table is distinguished by having a parent row in another
> table; rows in top-level tables do not have parents.  For relational
> databases, this usually means the child table has additional columns
> in the primary key to identify the parent row.
> Child objects cannot look up their parents directly, although if they
> do not have a parent object pointer, they must have a list of parent
> keys (to know where their children are and to write themselves out).
I don't see anything wrong with the database abstraction interface,
though there are a number of smaller problems that need to be solved.
For example, there's no way to query both the hierarchial text databases
and relational databases with just a procedural interface. This implies
we'll need a query language or something roughly approximating one; this
means we need to implement one for text databases. The relational
database backend also needs to maintain referential integrity, as well
as handle changes to the schema gracefully, of course.

> Each table type is represented by a descriptor and control object in
> srvx.  These are created by specifying the table name, column names
> and types, primary key column name, and factory to load objects from
> the database store.  These type descriptors are created by a factory
> method on the database backend object.
What if I hold a handle to an object and it gets deleted, then attempt
to use that handle?

# Zoot