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

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

Entrope <en...@us...> wrote:

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

Leaving out negative integers may make sense, since we really don't use
them. However, it would probably require a negligible amount of work to
support them, so there's no reason not to support them.

Backends that don't natively support a custom data type would probably
take the same approach the text database would -- serialize the data as
text. If we don't support custom data types (nothing wrong with that;
they're not essential), at least making new data types easy to add would
be helpful.

If we allow a web site to look at the data, it probably still needs to
go through srvx -- encapsulating "business logic" and all that (plus I'd
like to avoid duplicating code to deal with text databases).

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

When data absolutely has to be present in a column (which is not the
primary key), such as in the case of account passwords, it should be
enforced by the database layer. If a not null field is missing from an
insert or update, that row is completely invalid. An account without a
password is just as broken as an account without an account name.

# Zoot