are you using RoundCube with Postgres? If so, I'd really welcome your feedback (bug reports, patches, ...). I sure hope there is not much to report, but I guess when you use the "mdb2" backend it should work already.
No problems yet.
However, I have not yet upgraded to the latest RC, or a devel SVN
snapshot.
I use snapshot 274 ;)
Reasons to stay with such an old version :
Time 2) Don't want HTML message composing 3) Version we have does not generate problems
Sqlite - I am not sure how to really support that yet. Apparently there is a very old Sqlite2 still used and a "newer" Sqlite3.
3.4.x is the current stable, 3.5 is alpha.
2.x is _old_
PHP 5 comes bundled with a SQLite codebase, much like GD and the way
MySQL used to be with PHP 4.
PHP 5.1.4 comes bundled with 3.2.8, you can of course compile against
a version resident on your system.
I don't have a tarball of a newer 5.x version to poke into.
SQLite support for SQLite comes via PEAR/ PECL, and the latest
version of that extension uses SQLite 2.8.14
It would be interesting to know usage stats of Sqlite (along with version) in general so we could build stronger support. For example, I've heard from users that their Sqlite did not support "ALTER TABLE-like" commands, but that has been released maybe two years ago? So I am a bit unsure what we really need to support, etc..
Hmm, the current docs for that series of commands is here -- http://sqlite.org/lang_altertable.html Here is a quote from http://code.jenseng.com/db/
A major drawback to SQLite is that only the latest release (3.2.0)
supports the ALTER TABLE syntax, and the implementation is
incomplete (you can only rename tables and add columns). When you
consider that even the latest PHP releases are still bundled with a
pre-3.0 version of SQLite, altering tables can be a bit of a pain
for most users. If you want to alter a table, you have to create a
temporary table, copy the contents, delete the original, recreate
the original with new column definitions, copy the contents back,
and delete the temporary table.
One other drawback is that the file format changes as the versions
change.
A comment in the PHP live docs ( <http://www.php.net/manual/en/
ref.pdo-sqlite.php> ) quotes this from the PHP source code :
/* ** file_format==1 Version 3.0.0. ** file_format==2 Version 3.1.3. ** file_format==3 Version 3.1.4. ** ** Version 3.0 can only use files with file_format==1. Version 3.1.3 ** can read and write files with file_format==1 or file_format==2. ** Version 3.1.4 can read and write file formats 1, 2 and 3. */
It looks like there is also a file format change between 3.2.x and
3.3.x.
Fedora 7 ships with 3.3.13, for reference.
Fedora 8 has booted the compat package of SQLite v2.x out and will
update to 3.4.2
So it looks like support for SQLite will be quite the minefield, with
the possibility of any of several versions of SQLite with
incompatible file formats.
Once I get a bit more time, I'd like to test the SQLite backend.
For those that don't use the database to cache messages, SQLite might
be a good solution. I'm interested because our outside web server is
on the other side of the building from the database server, so a
small, local, flat-file database might actually produce better
performance.
We use SQLite with Director when we need to hook a database to that
beast, so I've used it some, although not hooked via PHP yet.
Charles Dostale System Admin - Silver Oaks Communications http://www.silveroaks.com/ 824 17th Street, Moline IL 61265
List info: http://lists.roundcube.net/dev/