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. ()
Configuration data should be stored in. 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. Readon 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.
Providing a GOM tutorial is beyond the scope of this document, but a.
GOM does allow access to the lower level SQLite query APIs. When using them, queries must be constructed using SQLite’s and API, rather than by constructing SQL strings then passing them to SQLite to parse. Constructing strings makes vulnerabilities very likely, which can give attackers access to arbitrary user data from the database.
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 fromand copy it into your project. It is licensed under LGPLv2.1+.
A full GVDB tutorial is beyond the scope of this document.
This work is licensed under a.
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.
Got a comment? Spotted an error? Found the instructions unclear? Send feedback about this page.