Pete Zaitcev ([info]zaitcev) wrote,
@ 2008-06-01 13:56:00
Previous Entry  Add to memories!  Tell a Friend!  Next Entry
Entry tags:linux, sqlite

Attack of Sqlite

Recently it became fashionable to link Sqlite everywhere (for example, yum uses it). The awsum workout that Firefox gives to your kjournald is also Sqlite. But now I see a little problem. What if anything happens to the database?

XML was bad enough, but it is repairable, if with a bigger difficulty than plain text. When GNOME eliminated battstat-applet, and started to throw an funny dialog, I was able to fix it by removing a few files and directories in my ~/.gconf (Thank you, Federico).

Now my Liferea develped a problem. One of the feeds has a phantom item in it: it shows one unread even if there aren't any unread items. If I click "Mark All Read", Liferea crashes. How am I supposed to repair this? I suppose there may be some command line tools coming with Sqlite which allow to issue SQL statements, but without knowing how the database is laid out, I cannot formulate such statements.

I expect this kind of thing to become more common as more people jump on the bandwagon.



(Post a new comment)

sqlite3, sqlitebrowser
[info]dnikulin
2008-06-01 11:23 pm UTC (link)
Yes, sqlite comes with a command line tool. For sqlite version 3, it'll just be sqlite3. Launch it with the database as an argument and you can execute SQL statements, including those you'd use to determine the schema.

Also try sqlitebrowser, "GUI editor for SQLite databases" according to my package repository.

sqlite3 guarantees that, filesystem/disk corruption aside, you will never have a corrupted database. The AID parts of ACID are supported, so only referential integrity is left to the application/framework. Unfortunately not all programs using sqlite use transactions properly, so their definition of corrupted is not useful. sqlite itself is not at fault.

(PS: I had to register an LJ account just to post this. Please consider allowing OpenID posts)

(Reply to this)


[info]fuhchee
2008-06-02 02:43 am UTC (link)
sqlite does seem to make it too easy for people to feel all warm and databasey, without doing the hard work of e.g. a proper schema design, performance/scaling analysis, fault recovery ("the database will handle it!").

(Reply to this) (Thread)


[info]zoratu
2008-06-02 06:16 am UTC (link)
yes, all those things make it wonderful for prototyping, and awful for unleashing upon innocent users.

(Reply to this) (Parent)


[info]loic
2008-06-02 05:14 pm UTC (link)
Yeah - end users or their desktop support people have to become DBAs. Since nobody has a file-format anymore, just a schema they don't have to worry about backward compatibility - they just have to hope their schema migration script works for everyone's data. And hope that nobody wants to downgrade. Oh, and SQLite isn't able to drop columns from tables so your file just grows and grows and grows.

*sigh*

I wish people would just look at what their requirements are and pick an appropriate technology rather than jumping on the latest bandwagon. SQLite is the new XML.

(Reply to this)


[info]jgreely
2008-06-02 07:30 pm UTC (link)
There are some documented data-corruption bugs in various versions of Sqlite, and OS crashes contribute their share as well. That said, it's better than having every programmer invent his own fragile, poorly-documented data store, and less painful to work with than XML (parsing JMdict was quite an adventure). Apple and Adobe are both actively pushing Sqlite into their applications and frameworks, which is a mixed blessing: they're smoking out the bugs and contributing patches, but they're putting it in places that I really rely on.

-j

(Reply to this)


Create an Account
Forgot your login?
Login w/ OpenID
English • Español • Deutsch • Русский…