March 4, 2018

My Micromount Database

This is a sort of "blog" style writeup of a project I am now working on. I have a collection of minerals that I view under the microscope and find it useful to maintain a database to keep track of what I have. I used to do this with a ruby on rails project, but I have come to hate rails so much that I decided to rewrite the whole thing as a non-web desktop application. The whole rails web thing was really unnecessary and a way for me to get my feet wet (not to mention burned) with rails.

So the idea now is to use ruby on a linux desktop along with sqlite3 (via the sqlite3 gem) and gtk2 to reproduce the old rails functionality.

gtk2 tips and resources

Doing things with gtk2 is always hard, but once you get it working, it does work, and seems to stay working, which is a lot more than you can say about rails (I'll try not to endlessly harp on how terrible rails is. If you knew how much I have suffered, you would certainly be patient with me.)

One thing I would like to do, is display a list of items and let the user make a choice from the list. Apparently this can be done using a ListStore in conjunction with a TreeView.

Sqlite3 and ruby

Thus far this has been smooth sailing. I have been able to take the database that I once used with rails (with 1008 entries) and begin writing plain ruby code to do queries. I contemplated using activerecord as a half step to rails freedom, but decided to go cold turkey. Activerecord has burned me with enough API changes over the years that I don't have overly fond feelings.

I find it curious, despite all the MVC rhetoric the rails propaganda hammered me with, that I am writing a nice tidy class to handle all my database interactions. MVC is a valid concept, but handled very badly in rails. In other words my own "model" is evolving quite naturally without all the rails discipline and bondage. Also, SQL is really no big deal. It is easier to deal with the well documented and stable SQL I need than a bunch of ever changing interfaces that are/were part of activerecord and not all that well documented. It just goes to show that people do better work when their creativity is allowed to run free than when they are beaten with sticks, but then we knew that already -- or did we?

Run with gtk3

This has turned out to not be too hard. A lot of things are the same, or at least similar, and there are very helpful deprecation warning messages that guide you almost all of the time to the new gtk3 API.

At this point in time there is no GTK3 documentation for ruby. So you use the ruby-gnome2 GTK2 documentation, along with various searches, and the excellent documentation for the C interface at the gnome developer site. Not ideal, but workable.

Dealing with color was a notable exception, it seems that they changed almost every aspect of the interface. The following post showed the way:

Probe more deeply into sqlite3

Here is a discovery. Column types of text and varchar are the same under sqlite although it keeps the label on the database columns as sort of "documentation". The same seems to be true of datetime, which ultimately can be stored as text or whatever. In the case of dates, sqlite offers utility functions to handle encoding and decoding, but it is up to you if you want to store text or a unix timestamp integer or whatever.

On Fedora, there are a couple of sqlite GUI gizmos. You can choose between sqliteman and sqlitebrowser. Both are available via dnf. After playing with them both, sqliteman seems easy to use, sqlitebrowser is confusing.

I have an autoincrement field called "id" as a relic from rails. What sqlite does is to generate a new value for this field if you do not supply a value, which sounds fine by me.

Feedback? Questions? Drop me a line!

Tom's Computer Info / [email protected]