[Dbconfig-common-devel] SQLite Support

[Matt Brown]

sean finney wrote:

> - could you go ahead and commit the "required changes" to trunk?  that
>   is, the checks for dbtypes supporting "remote" or "authenticated"
>   features.  i've made a few changes in trunk that will probably break
>   a couple parts of the diff but nothing severe.  this would be the
>   first step in bringing full support into trunk and will save us some
>   merging headaches later on as trunk continue to lurch forward with
>   unrelated fixes/additions.  also note that i've just sent 1.8.17
>   out the door so you may want to merge your branch with trunk before
>   merging back.

OK. I'll try and get to this this weekend.

> - do owner/mode really need to be prompted via debconf?  

OK, I'll remove the debconf questions for owner/mode and change the
default to root:root/640. Your reasoning sounds sane to me :)

> - some of the functions in internal/sqlite won't fail gracefully in the
>   case of code failure.  for example instead of:
<snip>
>   note that i'm not sure all of my code does it this way, though where
>   it doesn't that's a bug :)  otherwise, depending on how it's called
>   further up the chain it can cause the maintainer to prematurely exit
>   if it's running with "set -e"

Ah, yep. Will fix.

> - here's a bunch of "because i've never used sqlite" type questions:
>   - how are sqlite/sqlite2/etc different?  
>     - is it just file formats?
>     - sql/cmd syntax?  
>     - cmdline programs?  

SQLite3 is essentially a new file format, to preserve compatibility
there is basically a duplication of each component with a three appended
on the end, eg sqlite.h vs sqlite3.h, sqlite vs sqlite3 and so on.

The file format is completely incompatible, sqlite won't read a database
created by sqlite3, sqlite3 won't read a database by sqlite.

More details at:
http://www.sqlite.org/version3.html

>   - how many (or do any) applications support multiple sqlite versions
>     simultaneously?  

Not entirely sure. I believe that php5 contains extensions to read both
sqlite and sqlite3 databases.

I'm still grappling with what I'm going to do with SQLite for PHPwiki.
Currently all Debian PHPwiki installations use sqlite, sqlite3 provides
features that are useful (like support for ALTER TABLE) but to upgrade
cleanly I'd have to depend on sqlite, sqlite3, php-sqlite, php-sqlite3
which sounds like a nightmare.

I've not really looked into it in detail yet, but there is definitely
much work to do in this area.

>   - are the file formats anything like backwards compatible?

No, see above.

>   - are there commands to upgrade database formats?  if an app is likely to
>     change versions we could hypothetically make an upgrade hook similar
>     to the existing sql upgrade hooks.

The upgrade looks something like:

sqlite OLD.DB .dump | sqlite3 NEW.DB

>   - how many (or do any) applications require multiple database files?

Not many I suspect. A database file contain contain multiple tables, so
unless the application requires multiple postgres/mysql databases then
it shouldn't require multiple sqlite databases.

--
Matt Brown
matt at mattb.net.nz
Mob +64 21 611 544 www.mattb.net.nz

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 191 bytes
Desc: OpenPGP digital signature
Url : http://lists.alioth.debian.org/pipermail/dbconfig-common-devel/attachments/20060616/23270514/signature.pgp