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

[<en...@us...>]

"Zoot" <zo...@ga...> writes:

> 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.

What would we use a signed integer for?  (Where would we use negative
numbers?)  Bit vector would be a good idea to do portably across
databases, given how often we use it.  How would you implement loading
and storing types in SQL or BDB without the backend knowing how to do
the serialization in advance?  (I think having it all handled by the
front end is a poor idea, in case we allow a web site to look at the
data -- regardless of whether the web site can write to it.)

> It may be useful to allow schemas to specify that a column is 'not
> null,' as in SQL.

I was thinking "not null" could be handled at the application layer,
since that part of the schema has changed for columns between releases
(for example, some of the fields for gags) and only makes sense for
SQL.  How would we (gracefully) handle the case where a "not null"
field were missing from an insert or update?

> I don't see anything wrong with the database abstraction interface,
> though there are a number of smaller problems that need to be solved.

I discovered one: some objects have two logical parents (user entries
in channels belong to both the channel and the account).  To get
proper behavior for renames of the parent objects, the backend needs
to know this and support multi-column primary keys.

> 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.

You're probably right, although I was more concerned with the basic
functionality than how to do efficient searches.

> The relational database backend also needs to maintain referential
> integrity, as well as handle changes to the schema gracefully, of
> course.

Yes.  I tried to keep the schema simple enough to use easily but keep
enough information to tell let the SQL backend implement referential
integrity rules natively in SQL.

> What if I hold a handle to an object and it gets deleted, then attempt
> to use that handle?

Deleted from where?  If the C++ object exists after it was dropped
from the database, either the database manager knows it was dropped
(and will not write it back), or a third party dropped it (and the
UPDATE writeback command will fail in SQL; BDB would probably have to
make sure the row still exists before writeback).

Entrope