Philip Withnall
philip.withnall@collabora.co.uk 2015

This work is licensed under a Creative Commons Attribution-Share Alike 3.0 United States License.

As a special exception, the copyright holders give you permission to copy, modify, and distribute the example code contained in this document under the terms of your choosing, without restriction.

Simple persistent object stores
Daniel Mustieles
daniel.mustieles@gmail.com 2016-2020
Javier Mazorra
mazi.debian@gmail.com 2016, 2020

# Bases de datos

#

        Resumen

            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.
            ()

# Cuándo usar bases de datos

Los datos de configuración deben almacenarse en GSettings . Como regla general, si algunos datos deben ser persistentes y afectan el comportamiento de una aplicación, son datos de configuración. Si podría estar sujeto a políticas impuestas por el administrador del sistema (como la configuración de proxy o de bloqueo), son datos de configuración. Si contiene contenido creado por el usuario, no son datos de configuración y no deben almacenarse en 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 debe usarse si necesita funciones avanzadas, especialmente indexación. En otros casos debe usarse GVDB.

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.

# Usar GOM

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

## Inyección SQL

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.

# Usar 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+.

Un manual completo de GVDB está fuera del alcance de este documento.