On Sat, 12 May 2007 16:25:06 +0200 Ivan Voras <[EMAIL PROTECTED]> mentioned:
> It's not SQL I'm interested in, it's the "additional" features:
>
> - performance
> - transaction safety ("commit all changes or none")
> - constraints (like "unique" keys - sqlite unfortunately doesn't support
> foreign keys)
> - concurrent access (allowing to run multiple portupgrades at the same time)
> - easy interface to C programs
>
> If a BDB variety or some other storage layer can achieve these things,
> I'll likely support them.
>
> I know "Sleepycat" BDB implementations boast "transaction processing",
> but can they offer this across multiple stores / databases at the same
> time (i.e. like one transaction includes updates to multiple tables)?
> Efficient (performance-wise) storage would probably need to use more
> than one store, at least to index data by different keys.
>
I agree with everything, but, as was mentioned before, having such a
complex product in base will involve a lot of pain. Furthermore,
SQLite have a lot of features we don't need for our task.
Probably, we should just sit, document features we need and implement
required logic in e.g. bdb if not yet.
--
Stanislav Sedov
ST4096-RIPE
pgpawNyQ9fEhs.pgp
Description: PGP signature
