RE: [srvx-devel] draft: srvx-2.0 database abstraction interface
Brought to you by:
entrope
From: Zoot <zo...@ga...> - 2002-10-20 20:44:10
|
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 |