On Wed, Apr 3, 2013 at 5:11 PM, Tiago Rodrigues <wtrm...@gmail.com> wrote:
> Hello all, > > I'm writing a small simulation app and for it I would like to use SQLite3 > as an application file format, as suggested by the "Appropriate uses for > SQLite" page in sqlite.org. More specifically, the page suggests calling > BEGIN TRANSACTION when opening a file and calling COMMIT when saving it > again, or ROLLBACK if closing it without saving. > I wrote that text a long time ago - nearly a decade ago. Really, I think SQLite works even better as an application file format if you simply omit "File/Save" from the menu, and commit small transactions as you go. That way, if your application crashes or if your machine loses power, you don't lose any work. Here are some notes on how to implement undo/redo that works across sessions using triggers: http://www.sqlite.org/cvstrac/wiki?p=UndoRedo Consider, if you will, how the use of SQLite might improve an application. Let's think about the Open/Libra/NeoOffice presentation application. OpenOffice presentations do *not* use SQLite as an application file format. (In fairness, the program was designed and written long before SQLite had been invented.) Instead, presentations (the *.odp files) are stored as a ZIP archive containing files of XML, images, and other resources. A typical *.odp with lots of images runs about 10 or 20MB in size. When you start up OpenOffice, you have to wait 10 or 20 seconds for it to unpack the ZIP archive, then load and parse *all* of its XML and all of the images. The result is an annoying delay and a big memory footprint. If OpenOffice had used SQLite instead, it should simply query for the content of just the first slide and display that right away, with no delay, and without having to load the entire 150-slide presentation into memory first. OpenOffice (or it least the LibraOffice that comes installed on my Ubuntu desktop) tends to crash a lot. And when it does, I loss work. If the file format were SQLite instead, each edit would be saved as a separate transaction and no work would be lost after a crash. Perhaps because it crashing with such regularity, OpenOffice will periodically make an automatic backup of the presentation being edited. It takes a while (several seconds) to generate all of the necessary XML and images packed into a ZIP archive, and while this is going on, the screen is mostly locked up. The automatic backups can happen at any moment. So I might be typing in some text and then in the middle of a word it decides to do a backup, and my keyboard input stops working and I have to wait several seconds to continue. You cannot imagine how frustrating this is, especially when working on deadline. Furthermore, because it is writing the entire 20MB *.odp file, you are burning through 20MB of write on your life-limited SSD drive, when if fact you might have only changed a few bytes of text. None of these problems would even come up if the file format were SQLite instead. I've accumulated lots of presentation slides over the years. Wouldn't it be cool if these slides could all be tagged and then when constructing a new presentation I could search for existing slides using keywords. That would be a fairly trivial enhancement if the file format were an SQLite database instead of a ZIP-compressed pile-of-files. One could even consider using SQLite's built-in full-text search engine. Finally, the *.odp file format is inscrutable. It is very difficult to read or write without using OpenOffice. Third-party extensions cannot be easily added. If you want to write your own program to analyze or modify an OpenOffice presentation, you have to write lots of code that will decode and/or generate the custom OpenOffice pile-of-files format, which is a huge barrier to entry If the presentations were stored as SQLite databases, there is still some decoding and reverse-engineering that needs to be done, but substantially less - particularly if a reasonable schema is selected. This means that with SQLite as a file format, new applications can be more easily written to operate on your files. And because SQLite automatically takes care of concurrency control, you could even have two or more federates working on the same presentation at the same time! -- D. Richard Hipp d...@sqlite.org _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
