Sunday, August 30, 2015

python and sqlite

A previous post discussed the huge (250MB) installation of PostgreSQL for something as robust as a LAMP. However, suppose I just need a small database to keep track of business cards or some such?


Unlike PostgreSQL, SQLite has no server: everything is contained in a local "db" file you create. You can easily back it up by just backing up the file. To "connect" to the database, just go in the directory with that database and find the database, let's say it's "sample.db". Then...
$ sqlite3 sample.db
... and just do your business. Once complete, it's ".exit". Much easier for this kind of thing is a simple GUI, like sqliteman (Qt based).

Python access - APSW

But in our Python app, we'll want to access this database directly from the app, so we need a class of Python commands. If we want we can use SQLite commands and just import SQLite into the our code...
import os,sys,time
import sqlite3
... and use SQL language, intermixed with Python.

But if we want a wrapper with a set of Python classes, the easiest Arch module to install is APSW (# pacman -S apsw) which is technically a wrapper, not a module, but still provides a class for interacting with SQLite databases.

Once we have that, we can start our code with, say...
import os,sys,time
import apsw
...and and go on from there. However, I don't need any SQLite wrappers for the level of programming that I do --- I just write the database related commands in SQL. It's not that hard.

Python application

Remember that standalone Python programs are relatively simple to accomplish in Linux, but it depends on whether one compiles against a Python release and set of libs, or attempts to include these all in the package. Since most of what you run on your machine are scripts, like Bash scripts, the only thing you need to worry about among Python releases is what modules are natively available. The way to get to this is to first determine the highest version of Python on your system, and then see if you have modules you need to run your scripts.


Suppose I'm building a script that I want to create a GTK window for (or Qt, but lets use GTK in this example), and so I've got gtk3 and pygtk installed. I'm going to check the version of Python and then list its modules and see if it has gtk and pygtk modules.
$ python --version
Python 3.4.3
$ python3
Python 3.4.3 (default, Mar 25 2015, 17:13:50)
[GCC 4.9.2 20150304 (prerelease)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> help('modules')
[all modules are listed]
>>> exit()
I check the modules list and note gtk and pygtk are in the Python 2 modules list, but are not in the Python 3 modules list. Some Googling shows that Python 3 has a compatibility module, pygtkcompat, which emulates pygtk. All I need to do then is import pygtkcompat and configure it. Following that, I treat my code as gtk and pygtk existed. For example, the script might begin...
#! /usr/bin/python3

import os, sys, time
import pygtkcompat

# enable "gobject" and "glib" modules
pygtkcompat.enable_gtk(version='3.0') #matches shebang
import gtk
import glib
...and then whatever code came subsequently. Normal GTK "WINDOW" commands are available for example.

No comments: