-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
As you have correctly noted, the sqldb layer is nothing more than a very
thin layer around the mysql C API. So any limitations and design flaws
are entirely intentional :-) If you know of a library that provides a
better abstraction around multiple SQL database products, or would like to
write one, you have my blessing and encouragement!
On that note, poking around freshmeat.net I found one related project:
http://tazthecat.net/~isaac/sqloco/
It's a C++ wrapper around Postgres and MySQL. Worth a look, although I
can't say off hand if it would be any easier to take this guy's code than
it would be to develop our own.
The file system persistance layer has had the most use so far (it has
backed the interreality.org site using HyperVOS for over a year and a half
with no problems). However, when I did benchmarks a while ago, I noted
that the SQL persistance layer was several orders of magnitude faster
(both loading and saving). So SQL-backed persistance will be an important
component for sites with high dynamic load. An SQLite layer would be
particularly interesting, since it would avoid the overhead of sending
queries over a socket.
I've also been thinking about possibility of rewriting the revision
control persistance layer to use the Subversion filesystem. It's more of
an inkling, though, no firm near-term plans as there isn't a pressing need
for a more fully-featured revision control layer (yet).
On Sun, 27 Nov 2005, Lalo Martins wrote:
since we're at that :-)
Seems sqldb is a thin wrapper around the mysql api? It generally smells
of C. A few more things that sound funny:
- the escapeString() api smells of elderberries and is begging for a
buffer overflow. Come on, let's not propagate the design bugs of mysql.
- the getAffectedRows() method should be in SQLResult; it's a query
which affects rows, not a database.
- the lastError() method shouldn't even exist... I'm not sure other
database libraries implement something like that. It's only used in
sqlpersist.cc because selectDatabase() doesn't throw.
- how is SQLCell different from std::string?
- finally, I'm slightly uneasy about selectDatabase() and sqlpersist.cc
doing a 'CREATE DATABASE'. On a postgres adapter, it seems the
equivalent of selectDatabase() would be to close the underlying
connection and open a new one. On a sqlite adapter, I'm not even sure
it makes sense. I feel like sqlpersist should simply require the
database to pre-exist, and connect to the "right" one to begin with.
Sorry if this comes across as anything other than constructive
criticism; I do realize sqlpersist was written more as a proof of
concept. It's very useful, though, or it would be if you had other
choices than mysql :-)
I'm ready to put my metaphorical money where my mouth is, once I remove
my foot from there to have some space; I have a partially-written
postgres adapter (using libpqxx, it's a quite thin layer, but it doesn't
really work yet), and I can write a sqlite adapter too, once it's, well,
possible. I can even make the changes to sqldb and sqlpersist myself,
but since my c++ is still a work in progress, the code would probably be
less than perfect and require some review before it could go in the
repository.
[ Peter Amstutz ][ [EMAIL PROTECTED] ][ [EMAIL PROTECTED] ]
[Lead Programmer][Interreality Project][Virtual Reality for the Internet]
[ VOS: Next Generation Internet Communication][ http://interreality.org ]
[ http://interreality.org/~tetron ][ pgpkey: pgpkeys.mit.edu 18C21DF7 ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFDioq/aeHUyhjCHfcRAjG+AJ4lTUwXyvkH6KYV9V6Gh8HHn5Fl4QCeP91a
m50vHw9fRDr3WexV+QCpsYg=
=oI20
-----END PGP SIGNATURE-----
_______________________________________________
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
