> 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 : 1) 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/
