From 3c809bc011f331b6e876e542688d4795f2e6bbcb Mon Sep 17 00:00:00 2001
From: Boris Kolpackov Both the asociated table names and the column names can be qualified
+ with a database schema, for example: For more information on database schemas and the format of the
+ qualified names, refer to Section 12.1.8,
+ " Note also that in the above examples we specified the SQL type
for each of the columns to make sure that the ODB compiler
has knowledge of the actual types as specified in the database
@@ -8023,14 +8047,17 @@ for (bool done (false); !done; )
The qualifier tells the ODB compiler what kind of C++ construct
this pragma describes. Valid qualifiers are 12.1.5 optimistic
12.1.6 id
+ 12.1.7 callback
@@ -517,14 +518,21 @@ for consistency.
+ 12.1.8 schema
+
12.5 Namespace Pragmas
+
+
+
+
+ 12.5.1 schema
-
@@ -7045,6 +7053,22 @@ struct employee_max_vacation
};
+ 12.5 C++ Compiler Warnings
+ 12.6 C++ Compiler Warnings
-
- 12.5.1 GNU C++
- 12.5.2 Visual C++
- 12.5.3 Sun C++
- 12.5.4 IBM XL C++
+ 12.5.5 HP aC++
+ 12.6.1 GNU C++
+ 12.6.2 Visual C++
+ 12.6.3 Sun C++
+ 12.6.4 IBM XL C++ 12.6.5 HP aC++
+#pragma db view table("hr.employee_extra")
+struct employee_max_vacation
+{
+ #pragma db column("hr.employee_extra.vacation_days") type("INTEGER")
+ unsigned short vacation_days;
+};
+
+
+ schema
".object
,
- view
, value
, and member
.
- A pragma with the object
qualifier describes a persistent
- object type. It tells the ODB compiler that the C++ class it
- describes is a persistent class. Similarly, pragmas with the
- view
qualifier describe view types, the value
- qualifier describes value types and the member
- qualifier is used to describe data members of persistent object,
- view, and value types.view
, value
, member
, and
+ namespace
. A pragma with the object
+ qualifier describes a persistent object type. It tells the ODB
+ compiler that the C++ class it describes is a persistent class.
+ Similarly, pragmas with the view
qualifier describe
+ view types, the value
qualifier describes value types
+ and the member
qualifier is used to describe data
+ members of persistent object, view, and value types. The
+ namespace
qualifier is used to describe common
+ properties of objects, views, and value types that belong to
+ a C++ namespace.
The specifier informs the ODB compiler about a particular database-related property of the C++ declaration. For example, the @@ -8171,7 +8198,7 @@ class person the C++ compiler to build the application. Some C++ compilers issue warnings about pragmas that they do not recognize. There are several ways to deal with this problem which are covered - at the end of this chapter in Section 12.5, + at the end of this chapter in Section 12.6, "C++ Compiler Warnings".
schema
table
If the table name is not specified, the class name is used as the - table name.
+ table name. The table name can be qualified with a database + schema, for example: + ++#pragma db object table("census.people") +class person +{ + ... +}; ++ +
For more information on database schemas and the format of the
+ qualified names, refer to Section 12.1.8,
+ "schema
".
pointer
schema
The schema
specifier specifies a database schema
+ that should be used for a persistent class.
In relational databases the term schema can refer to two related + but ultimately different concepts. Normally it means a collection + of tables, indexes, sequences, etc., that are created in the + database or the actual DDL statements that create these + database objects. Some database implementations support what + would be more accurately called a database namespace + but is also called a schema. In this sense, a schema is a + separate namespace in which tables, indexes, sequences, etc., + can be created. For example, two tables that have the same + name can coexist in the same database if they belong to + different schemas. In this section when we talk about a + schema, we refer to the database namespace meaning + of this term.
+ +When schemas are in use, a database object name is qualified + with a schema. For example:
+ ++CREATE TABLE accounting.employee (...) + +SELECT ... FROM accounting.employee WHERE ... ++ +
In the above example accounting
is the schema
+ and the employee
table belongs to this
+ schema.
Not all database implementations support schemas. Some
+ implementation that don't support schemas (for example,
+ MySQL, SQLite) allow the use of the above syntax to specify
+ the database name. Yet others may support several levels
+ of qualification. For example, Microsoft SQL Server has
+ three levels starting with the linked database server,
+ followed by the database, and then followed by
+ the schema:
+ server1.company1.accounting.employee
.
+ While the actual meaning of the qualifier in a qualified name
+ vary from one database implementation to another, here we
+ refer to all of them collectively as a schema.
In ODB, a schema for a table of a persistent class can be
+ specified at the class level, C++ namespace level, or the
+ file level. To assign a schema to a specific persistent class
+ we can use the schema
specifier, for example:
+#pragma db object schema("accounting") +class employee +{ + ... +}; ++ +
If we are also assigning a table name, then we can use
+ a shorter notation by specifying both the schema and
+ the table name in the table
specifier:
+#pragma db object table("accounting.employee") +class employee +{ + ... +}; ++ +
If we want to assign a schema to all the persistent classes + in a C++ namespace, then, instead of specifying the schema + for each class, we can specify it once at the C++ namespace level. + For example:
+ ++#pragma db namespace schema("accounting") +namespace accounting +{ + #pragma db object + class employee + { + ... + }; + + #pragma db object + class employer + { + ... + }; +} ++ +
Similar to other qualifiers, the namespace
qualifier
+ can also refer to a named C++ namespace, for example:
+namespace accounting +{ + ... +} +#pragma db namespace(accounting) schema("accounting") ++ +
If we want to assign a schema to all the persistent classes in
+ a file, then we can use the --schema
+ ODB compiler option. For example:
+odb ... --schema accounting ... ++ +
The alternative to this approach with the same effect is to
+ assign a schema to the global namespace. To refer to the global
+ namespace in the namespace
qualifier we use
+ the following special syntax:
+#pragma db namespace() schema("accounting") ++ +
By default schema qualifications are accumulated starting from
+ the persistent class, continuing with the namespace hierarchy
+ to which this class belongs, and finishing with the schema
+ specified with the --schema
option. For
+ example:
+#pragma db namespace schema("audit_db") +namespace audit +{ + #pragma db namespace schema("accounting") + namespace accounting + { + #pragma db object + class employee + { + ... + }; + } +} ++ +
If we compile the above code fragment with the
+ --schema server1
option, then the
+ employee
table will have the
+ server1.audit_db.accounting.employee
qualified
+ name.
In some situations we may want to prevent such accumulation
+ of the qualifications. To accomplish this we can use the
+ so-called fully-qualified names, which have the empty leading
+ name component. This is analogous to the C++ fully-qualified
+ names in the ::accounting::employee
form. For
+ example:
+#pragma db namespace schema("accounting") +namespace accounting +{ + #pragma db object schema(".hr") + class employee + { + ... + }; + + #pragma db object + class employer + { + ... + }; +} ++ +
In the above code fragment, the employee
table will
+ have the hr.employee
qualified name while the
+ employer
— accounting.employer
.
+ Note also that the empty leading name component is a special
+ ODB syntax and is not propagated to the actual database names
+ (using a name like .hr.employee
to refer to a table
+ will most likely result in an error).
Auxiliary database objects for a persistent class, such as indexes,
+ sequences, triggers, etc., are all created in the same schema
+ as the class table. By default, this is also true for the
+ container tables. However, if you need to store a container
+ table in a different schema, then you can provide a qualified
+ name using the table
specifier, for example:
+#pragma db object table("accounting.employee") +class employee +{ + ... + + #pragma db object table("operations.projects") + std::vector<std::string> projects_; +}; ++ +
The standard syntax for qualified names used in the
+ schema
and table
specifiers as well
+ as the view column
specifier (Section
+ 12.4.8, "column
(view)") has the
+ "
name.
name..."
+ form where, as discussed above, the leading name component
+ can be empty to denote a fully qualified name. This form, however,
+ doesn't work if one of the name components contains periods. To
+ support such cases the alternative form is available:
+ "
name"."
name"
...
+ For example:
+#pragma db object table("accounting_1.2"."employee") +class employee +{ + ... +}; ++ +
Finally, to specify an unqualified name that contains periods + we can use the following special syntax:
+ ++#pragma db object schema(."accounting_1.2") table("employee") +class employee +{ + ... +}; ++
A pragma with the view
qualifier declares a C++ class
@@ -9987,6 +10264,24 @@ class person
to Section 7.2.1, "Composite Value Column and Table
Names" for details.
The container table name can be qualified with a database + schema, for example:
+ ++#pragma db object +class person +{ + ... + + #pragma db table("extras.nicknames") + std::vector<std::string> nicknames_; +}; ++ +
For more information on database schemas and the format of the
+ qualified names, refer to Section 12.1.8,
+ "schema
".
index_type
The index_type
specifier specifies the native
@@ -10268,7 +10563,37 @@ class person
If the column name is not specified, then value
is used by default.
A pragma with the namespace
qualifier describes a
+ C++ namespace. The qualifier can be optionally followed,
+ in any order, by one or more specifiers summarized in the
+ table below:
Specifier | +Summary | +Section | +
---|---|---|
schema |
+ database schema for persistent classes inside a namespace | +12.5.1 | +
schema
The schema
specifier specifies a database schema
+ that should be used for persistent classes inside a namespace.
+ For more information on specifying a database schema refer to
+ Section 12.1.8, "schema
".
When a C++ header file defining persistent classes and containing ODB pragmas is used to build the application, the C++ compiler may @@ -10321,7 +10646,7 @@ class person
The disadvantage of this approach is that it can quickly become overly verbose when positioned pragmas are used.
-GNU g++ does not issue warnings about unknown pragmas
unless requested with the -Wall
command line option.
@@ -10333,7 +10658,7 @@ class person
g++ -Wall -Wno-unknown-pragmas ...
-
Microsoft Visual C++ issues an unknown pragma warning (C4068) at warning level 1 or higher. This means that unless we have disabled @@ -10367,7 +10692,7 @@ class person #pragma warning (pop) -
The Sun C++ compiler does not issue warnings about unknown pragmas
unless the +w
or +w2
option is specified.
@@ -10379,7 +10704,7 @@ class person
CC +w -erroff=unknownpragma ...
-
IBM XL C++ issues an unknown pragma warning (1540-1401) by default.
To disable this warning we can add the -qsuppress=1540-1401
@@ -10389,7 +10714,7 @@ CC +w -erroff=unknownpragma ...
xlC -qsuppress=1540-1401 ...
-
HP aC++ (aCC) issues an unknown pragma warning (2161) by default.
To disable this warning we can add the +W2161
diff --git a/odb/options.cli b/odb/options.cli
index 18bd232..1a0d0c1 100644
--- a/odb/options.cli
+++ b/odb/options.cli
@@ -88,9 +88,11 @@ class options
{
"