QDB开发者指南：QNX Software Development Platform 6.6

需积分: 11 148 浏览量更新于2024-07-18 收藏 1.04MB PDF 举报

"QDB Developer's Guide 是针对 QNX 操作系统的 QDB 数据库服务器的一份开发者指南，主要面向应用开发人员，适用于 QNX Software Development Platform 6.6 版本。该指南由 QNX Software Systems Limited（BlackBerry 的子公司）出版，并提供了关于如何使用 QDB 进行数据库开发的详细信息。" 在 QDB Developer's Guide 中，开发者将了解到以下关键知识点： 1. **QNX Software Development Platform 6.6**：这是 QNX 操作系统的版本，为开发者提供了一个集成的环境来构建、调试和部署嵌入式软件。这个平台支持 QDB 数据库服务器，是开发基于 QNX 系统应用的基础。 2. **QDB（QNX Database）**：QDB 是 QNX 操作系统中的一个关系型数据库管理系统，用于在嵌入式系统中存储和管理数据。它可能包含事务处理、并发控制和恢复机制等核心数据库功能。 3. **Getting Started with QDB**：这一章介绍了如何启动 QDB 服务器，包括必要的配置步骤。学习者将了解如何启动和停止服务器，以及如何加载和卸载数据库。 4. **Starting the QDB server**：启动 QDB 服务器是使用其功能的第一步。这部分会讲解启动命令和可能的配置选项，以确保服务器正确运行。 5. **Loading and Unloading QDB databases**：加载数据库允许应用程序访问其中的数据，而卸载则释放资源。这部分将介绍如何执行这些操作，以及可能的注意事项。 6. **PPS configuration path**：PPS（Persistent Process State）配置路径可能是指服务器如何保存和恢复其状态，对于系统重启后的服务恢复至关重要。 7. **Database configuration objects**：这些对象定义了数据库的结构和参数设置，包括安全性、性能优化和备份策略等。 8. **Database storage**：这部分涵盖了数据库的存储机制，包括数据文件的组织、磁盘空间管理和内存使用。 9. **Schema files**：模式文件定义了数据库的架构，包括表、列、索引和约束。它们是理解和操作数据库的关键。 10. **Summary of database files**：列出所有与数据库相关的文件类型及其用途，有助于理解数据库的物理结构。 11. **QDB Command Line**：开发者可以使用命令行工具与 QDB 交互，进行数据操作、查询和管理任务。这部分会介绍命令行工具的使用和各种命令的语法。 12. **Temporarystorage filesystem**：临时存储文件系统可能指的是数据库在运行时用于存储临时数据的区域，这对于处理大量瞬态数据的应用来说非常重要。 13. **Database integrity testing**：为了确保数据的完整性和一致性，QDB 提供了检测和修复数据错误的工具和机制。 14. **Sharing connections**：在多用户环境中，如何共享数据库连接和资源管理是提高效率的关键。这份指南通过深入浅出的讲解，帮助开发者充分利用 QDB 数据库的功能，进行高效、可靠的嵌入式应用开发。每个章节都提供了详细的操作指南和技术细节，是 QNX 平台下数据库开发者的宝贵参考资料。

You can then override the PPS configuration path by starting QDB with the -c option,

as in the following example:

qdb -c /temp/qdb

The directory named in the PPS configuration path must exist before you start QDB.

You can launch multiple instances of QDB with different configuration paths so long

as each path is based on the PPS mountpoint. So in the above example, you could

also run an instance of QDB with the PPS configuration path /temp/customerdbs.

We recommend you use separate QDB device mountpoints for separate QDB instances;

this is done with the -n option on the qdb command line. For details, see the QDB

Command Line (p. 25) chapter.

Getting Started with QDB

Database configuration objects

QDB databases are managed with configuration objects, each of which configures one

database. The configuration objects are text files that specify the paths to the database

schema and storage files as well as policy settings such as backups.

The files are named after the databases that they configure. For example, suppose

you have two media content databases named hdd and cdrom. You would then create

two configuration objects named hdd and cdrom. For an overview of all

database-related files, see “Summary of database files (p. 24)”.

By using a separate SQLite storage file for each database, QDB allows you to

dynamically load and unload individual databases so you can keep in memory only

the data needed for the active client application.

QDB doesn't support “on-the-fly” configuration changes after a database is

loaded. To modify the configuration, you must unload the database, update

its configuration object, and reload the database. You must also ensure that

the changes are compatible with the previous configuration.

Configuration object contents

The database configuration object gets parsed by QDB to set up the database. Lines

specifying parameters are in the form key::value. Unknown parameter types are

ignored and so they can be made into comments, but you must still use the :: delimiter

on the comment line. For example, you can enter MyComment:: on a line and QDB

will treat it as an unsupported parameter and ignore that line when parsing the file.

The configuration object must contain a Filename parameter that refers to the

database storage file. All other parameters are optional. For an example of a database

configuration, see “Sample configuration object (p. 21)”.

The database can be configured with the following parameters:

Filename::

The name of the database file, which is the raw SQLite file. It must have an

absolute path but it can refer to any file location. At database loading time,

either this file or the directory in which it will be created must exist;

otherwise, the loading attempt fails and QDB sets the status to Error. If the

database file doesn't exist but it's parent directory does, the file is restored

from the newest valid backup (if possible) or a blank database file is created.

SchemaFile::

Database configuration objects

The name of the file (with an absolute path) that contains the SQL commands

to create the initial schema of tables, indexes, and views of a new database.

The schema file is used only to set up the database if it didn't already exist.

An initial schema is optional; without an initial schema, a new database will

just be empty.

DataSchemaFile::

The name of the file (with an absolute path) that creates the initial data in

the database. This text file contains the SQL commands to populate a

database when it is created.

Note that this option is processed only if the Schema File option is set.

ClientSchemaFile::

The name of the client schema file (with an absolute path) that contains

the SQL commands to execute every time a client calls qdb_connect() (p.

125).

Use this feature for changing database settings that can't be premanently

modified. An example would be the PRAGMA commands, which modify

non-table data such as journaling mode or case-sensitive-like status. Don't

use client schema files to do regular database work because doing so will

slow down new connections.

You can also use this mechanism to implement cross-database triggers.

AutoAttach::

A list of other databases to attach to the current one (using the SQL ATTACH

DATABASE statement) whenever a database connection is established. List

entries are separated by commas.

Attached databases are a convenience to provide access to tables that are

physically stored in a different database file. This is useful for breaking up

a database into separate pieces for performance reasons (each piece gets

its own lock, which makes multi-user access more responsive). It's also

useful for moving parts of a database to different storage medias (such as

a RAM filesystem).

QDB allows you to include attached databases in other maintenance

operations, such as backup or vacuum.

If any attached database is unavailable at loading time, QDB sets

the current database's status to AttachWait and makes the database

inaccessible.

Getting Started with QDB

BackupDir::

A list of the directories that store database backups. List entries are separated

by commas. When you specify multiple directories, they're used in rotation

to store the backup files. This feature ensures that should a backup be

interrupted or aborted by a power failure, another older backup is still

available.

These directories must exist at loading time (though they don't need to

contain valid backups); otherwise the loading attempt fails and QDB sets

the database status to Error. If any existing backup files are located in these

directories, they are sorted by date and overwritten oldest-to-newest when

performing backup operations, and used in newest-to-oldest order when

restoring a missing or corrupt database.

Compression::none | lzo | bzip | diocopy

The compression algorithm to apply to backups. The supported options are

none (for no compression), lzo (for LZO compression), bzip (for BZIP2

compression), or diocopy (for direct I/O copy).

The lzo compression algorithm is the fastest, but the bzip algorithm offers

the highest compression. Direct I/O doesn't perform any compression; instead,

QDB uses an external utility to copy the database using direct memory access

(DMA). Direct I/O is a fast way to back up data if the persistent storage

supports DMA.

The compressed files are created with appropriate extensions added to the

original database filename. By default, backup files aren't compressed.

Collation::, Function::

These entries install user-provided collation (sorting) routines and user

scalar/aggregate functions respectively. The argument format is a

comma-separated list of library symbols in the form tag@library.so, where

tag is the symbol name of the function description structure and library.so

is the name of the shared library containing the code.

Unlike the paths to other key files, the library file path can be relative or

absolute. Relative paths are searched for in the library search directories

(refer to the QNX Neutrino C Library Reference on dlopen() for more detail).

You can also specify symbols from as many shared libraries as you want.

For example, you could write:

Collation::UTF-8_Sort@libsort.so,UTF-16_Sort@libsort.so

Function::sampleData@libstats.so,implToMtrc@libunits.so

For more information, see the Writing User-Defined Functions (p. 93) chapter.

Database configuration objects

QDB checks for the existence of the libraries and the specified symbols at

loading time, and if any are not found, the loading attempt fails and QDB

sets the database status to Error.

VacuumAttached::, BackupAttached::, SizeAttached::

These entries control what maintenance operations should apply by default

to attached databases when a command is issued to the main database.

Each parameter is set to a comma-separated list of databases to which the

operation is applied.

Here's a sample configuration for a database named mp3_tunes_0:

Filename::/fs/tmpfs/mp3_tunes_0

AutoAttach::mp3_tunes_1,mp3_tunes_2

VacuumAttached::mp3_tunes_1

In this example, a qdb_vacuum() (p. 178) operation on mp3_tunes_0 will

also vacuum mp3_tunes_1 but not mp3_tunes_2.

Any database named in an operation-specific attachment list such

as VacuumAttached must also be named in the AutoAttach list, or

that database won't be processed during the operation.

For more details on the scope of maintenance operations for attached

databases, refer to qdb_vacuum() (p. 178), qdb_backup() (p. 106), and

qdb_getdbsize() (p. 131).

BackupVia::

This entry specifies an interim directory into which the database is copied

as part of the backup. To make sure the backup is consistent, QDB places

a read lock on the database while copying and compressing it, so the

database may be locked a long time if the destination is slow (for example,

flash).

For example, you could specify BackupVia::/dev/shmem. When backing

up, QDB locks the database, copies it to /dev/shmem, and then releases

the lock. Then, in a second step, QDB performs the copy and compress

operation into the location specified by BackupDir::, without needing to lock

the database.

CompressionVia::TRUE | FALSE

This entry is used in conjunction with the BackupVia:: entry and any

Compression:: setting specified for the backup. By default, the BackupVia::

feature first makes a raw/uncompressed copy of the database in the temporary

directory and then performs the compression as the second step. This works

Getting Started with QDB

剩余235页未读，继续阅读

hushuo0428

粉丝: 2
资源: 33

QDB开发者指南：QNX Software Development Platform 6.6

QNX6.6_Quickstart_Guide.pdf

QDB:经过优化的基于文档SQL数据库

qdb_dev_guide.pdf

钱袋宝qdb-1349

qdb (9).xls

qdb (1).xls

qdb:基于leveldb的kv数据库

qdb-api-r：官方quasardb R API

Qdb:Qiling Framework催生的多架构和跨平台调试器

Samsung三星NP950QDB i7-1165G7原装原厂10出厂自带系统

最新资源