Re: Considering glom but one major hurdle - I don't really want postgresql

[Chris Green <cl isbd net>]

On Thu, Jan 19, 2012 at 11:24:11AM +0100, Murray Cumming wrote:
> On Tue, 2012-01-10 at 16:50 +0000, Chris Green wrote:
> [snip]
> > For a database which is always going to be associated with a particular
> > host (which is nearly all home user database usage) it's way more
> > convenient to use sqlite.  There are no issues with extra user/passwords
> > needed for the database and no issues with backing up the database as
> > it's "just another file" in the local data associated with the
> > application.
>
> But for all the cases where you do want those features, sqlite obviously
> isn't enough. So, Glom currently uses PostgreSQL by default to:
> 1. avoid the work of maintaining and testing two backends
> 2. avoid asking the user an obscure question about what backend he wants
> to use.
> 3. avoid having to migrate data to PostgreSQL later when the user
> decides he want the extra features.
>
> But we keep the sqlite backend around just in case it would be useful in
> embedded devices, where a custom Glom build would be necessary anyway.
> It also encourages us to abstract the Glom code appropriately.
Yes, OK, all reasonable arguments.  I can see why you're doing it the
way you're doing it, just doesn't happen to suit me.

Sqlite has one *big* advantage, the database resides in a file which
usually by default is in a place that gets backed up with the web pages,
in contrast to mySql or postgresql where the databases are usually
somewhere that one forgets to back up and also need special backup
strategies. 


> > I always choose sqlite when I can, I don't think I have *any* database
> > applications where it wouldn't make things easier.  Even web
> > applications (which nearly *all* use mySql) work perfectly well with
> > sqlite as long as they're not so big that one needs to split the web
> > server away from the database.  On a home LAMP system that's never going
> > to happen.
> >
> > When you say "There is also an Sqlite example" do you mean the code is
> > in place to use sqlite?  Or what do I need to do to try it?
>
> Yes, though you need to specify --enable-sqlite when building Glom from
> source. You will then see it as an option in the UI when creating new
> Glom files.
OK, so I'll have to build it myself to get sqlite support, not too big a
problem. 


> There is at least one known bug and you might find more:
> https://bugzilla.gnome.org/show_bug.cgi?id=600874#c20
> though Glom's regression tests do run with both the sqlite backend as
> well as the PostgreSQL one.
OK.

> Overall, I think it would be best (or also advisable) to push for
> PostgreSQL support in DokuWiki.
Dokuwiki itself doesn't use *any* database, which is one of the major
reasons I chose to use it.  All the wiki pages are stored as text files
which, if you want, you can edit directly rather than through the wiki.

What uses sqlite (and also mySql as an alternative) is a Dokowiki plugin
that I happen to use.  Since it uses PHP's PDO interface it will
probably work with little or no change with postgresql.  I'd need to
copy my databases of course.

Thanks for the feedback.

-- 
Chris Green