Hacker News Reader

Comment by viraptor | Hacker News Reader

I don't like that idea, because of one simple limit. You cannot diff databases (easily). Of course you can dump them, make sure the linebreaks are there between records, make sure they're sorted, etc. etc. But checking the whole config in or out of a VCS is much more useful in general. It also provides an easy to browse record of changes.

View on HN

I'm aiming for operational understanding of the data model used over being able to directly work with the config file. If it's a .ini (or other conf) usually you have no idea how the config maps to internal data structures. It's a mystery why some stanzas in nginx work on FastCGI but not Proxies for example.

With a sqlite3 based "config file" you'll be able to use real, turing complete languages to configure it, create control pannels, distribute the config reliably, and you can run .schema to figure out how it's structured.

It's also incredibly reliable and has many great features for this kind of thing.

Isn't the nginx's problem solvable with consistent implementation and complete documentation too?

I guess running some programming script isn't that bad to configure the server - but right now, people do a lot of basic operations on configs via shell scripting which do the deployment. Using bash/sh to interact with sqlite doesn't sound very inviting.

Possibly, it's a littler early to tell, but I'm sure I'll make it easy to use from the shell. Could even be possible to create converters from other config file formats to the Mongrel2 data model as well.

Think of it like this. Zed is combining Apache's nonstandard configuration language with it's internal runtime representation of such. He's doing it in a way that's standard and manipulable at runtime. So changes to the runtime configuration are persistent. You can fix that. That's the beauty of it. It's an incredibly simple and flexible idea that builds upon existing, robust, and standard software. If you want to diff config files, then you could slap together an XML, JSON, or any other representation of your config data and write a loader for it.

Isn't reading from sqlite all the time a bit bad for the performance?

Wouldn't the server only read it after a config option has been changed? I don't think the server is going to check this database every time a request comes in.

adamtj said "manipulable at runtime", so I guess he meant the changes are available directly after an UPDATE.

How can you tell if the config is changed? You either poll it every time with SELECT (SQL) or see if the timestamp of the database file has changed. (If SQLite works this way. I never had the need to check on the file status.) This costs time as well.

Other web servers have a config file and reload it after getting signalled.

But: It's a bit early to say what Zed intends with SQLite. Maybe mongrel2 gets a configuration interface like Cherokee and only reads the DB on startup and after getting signalled.

If diffing is important, why not use Git as the repository back-end, then?

It doesn't matter which VCS. If you check in text, you can review the changes. If you checkin databases, all you get is a blob. Git is not magic and will not solve this problem.

The sqlite database might get stored as a blob, but a json, xml, or sql dump of the database would be just as plain text as anything else.

Reply on news.ycombinator.com