Philip Withnall
philip.withnall@collabora.co.uk 2015
Simple persistent object stores

# Databases

#

        Sumar

            Use databases for appropriate use cases: not configuration data (use
            GSettings). ()

            Choose between GOM and GVDB based on whether indexing is required.
            ()

            Consider your vacuuming policy before committing to using GOM.
            ()

            Avoid SQL injection vulnerabilities by using prepared statements.
            ()

# When to Use Databases

Configuration data should be stored in GSettings. As a rule of thumb, if some data needs to be persistent and affects how an application behaves, it is configuration data. If it could potentially be subject to policies imposed by the system administrator (such as proxy or lockdown settings), it is configuration data. If it contains user created content, it is not configuration data, and should not be stored in GSettings.

For such situations where user data is highly structured, storing it in a database is sensible. There are two main databases suggested for use within GNOME: GOM and GVDB. GOM is a wrapper around SQLite, and hence implements indexing of fields and SQL-style queries. GVDB is a much simpler object store, supporting fast serialization of a dictionary of objects to disk.

GOM should be used if you need advanced features, especially indexing. GVDB should be used otherwise.

Before deciding to use GOM (and hence SQLite), you must consider a vacuuming policy for the database, and whether your use case will interact well with SQLite’s vacuuming system. Vacuuming is effectively SQLite’s term for defragmenting the database — if a database is not vacuumed appropriately, performance will degrade and the database size will increase indefinitely. Read this article on vacuuming for more information; please consider it before choosing to use GOM.

GNOME has another database library: GNOME Data Access (GDA). This is targeted at abstracting access to various types of relational database, for use in a database utility program or office program, for example. It is not suitable for storing user settings.

# Using GOM

Providing a GOM tutorial is beyond the scope of this document, but a reference manual is available.

## SQL Injection

GOM does allow access to the lower level SQLite query APIs. When using them, queries must be constructed using SQLite’s prepared statement and value binding API, rather than by constructing SQL strings then passing them to SQLite to parse. Constructing strings makes SQL injection vulnerabilities very likely, which can give attackers access to arbitrary user data from the database.

# Using GVDB

GVDB has a simple API which mirrors a conventional hash table. Presently, GVDB is only available as a copy-and-paste library; fetch the most recent copy of the code from GVDB git and copy it into your project. It is licensed under LGPLv2.1+.

A full GVDB tutorial is beyond the scope of this document.