- 21.1 | Basic Types Library
+ | 22.1 | Basic Types Library
|
- 21.2 | Smart Pointers Library |
- 21.3 | Containers Library |
+ 22.2 | Smart Pointers Library |
+ 22.3 | Containers Library |
- 21.4 | Date Time Library
+ | 22.4 | Date Time Library
|
@@ -1551,7 +1559,7 @@ main (int argc, char* argv[])
database name, etc., from the command line. In your own applications
you may prefer to use other mysql::database
constructors which allow you to pass this information directly
- (Section 14.2, "MySQL Database Class").
+ (Section 15.2, "MySQL Database Class").
Next, we create three person
objects. Right now they are
transient objects, which means that if we terminate the application
@@ -2083,7 +2091,7 @@ odb::mysql::database db2 ("john", "secret", "test_db2");
tight integration with specific database systems to being able to
write database-agnostic code and loading individual database systems
support dynamically. While all these aspects are covered in detail
- in Chapter 13, "Multi-Database Support", in this
+ in Chapter 14, "Multi-Database Support", in this
section we will get a taste of this functionality by extending our
"Hello World" example to be able to store its data either in MySQL
or PostgreSQL (other database systems supported by ODB can be added
@@ -2100,8 +2108,8 @@ odb --multi-database dynamic -d common -d mysql -d pgsql \
The --multi-database
ODB compiler option turns on
multi-database support. For now it is not important what the
- dynamic
value that we passed to this option means,
- but if you are curious, see Chapter 13. The result of this
+ dynamic
value that we passed to this option means, but
+ if you are curious, see Chapter 14. The result of this
command are three sets of generated files: person-odb.?xx
(common interface; corresponds to the common
database),
person-odb-mysql.?xx
(MySQL support code), and
@@ -2925,6 +2933,10 @@ namespace odb
static bool
reset_current ();
+
+ // Callback API.
+ //
+ ...
};
}
@@ -3014,6 +3026,9 @@ for (size_t i (0); i < n; ++i)
t.commit ();
+
For more information on the transaction callback support, refer
+ to Section 13.1, "Transaction Callbacks".
+
Note that in the above discussion of atomicity, consistency,
isolation, and durability, all of those guarantees only apply
to the object's state in the database as opposed to the object's
@@ -3091,6 +3106,9 @@ update_age (database& db, person& p)
}
+
See also Section 13.1, "Transaction Callbacks"
+ for an alternative approach.
+
The odb::connection
class represents a connection
@@ -7393,7 +7411,7 @@ namespace odb
consider using a more efficient implementation of the
optional value concept such as the
optional
class template from Boost
- (Section 20.4, "Optional Library").
+ (Section 21.4, "Optional Library").
Another common C++ representation of a value that can be
NULL
is a pointer. ODB will automatically
@@ -13880,6 +13898,164 @@ class person
+
+
+
+
+
+
+ This chapter covers more advanced techniques and mechanisms
+ provided by ODB that may be useful in certain situations.
+
+
+
+ The ODB transaction class (odb::transaction
) allows
+ an application to register a callback that will be called after
+ the transaction is finalized, that is, committed or rolled back.
+ This mechanism can be used, for example, to restore values that
+ were updated during the transaction execution to their original
+ states if the transaction is rolled back.
+
+ The callback management interface of the transaction
+ class is shown below.
+
+
+namespace odb
+{
+ class transaction
+ {
+ ...
+
+ public:
+ static const unsigned short event_commit = 0x01;
+ static const unsigned short event_rollback = 0x02;
+ static const unsigned short event_all = event_commit | event_rollback;
+
+ typedef void (*callback_type) (
+ unsigned short event, void* key, unsigned long long data);
+
+ void
+ register_ (callback_type callback,
+ void* key,
+ unsigned short event = event_all,
+ unsigned long long data = 0,
+ transaction** state = 0);
+
+
+ void
+ unregister (void* key);
+ }
+}
+
+
+ The register_()
function registers a
+ post-commit/rollback callback. The callback
+ argument is the function that should be called. The
+ key
argument is used by the transaction
+ to identify this callback. It is also normally used
+ to pass an address of the data object on which the
+ callback function will work. The event
+ argument is the bitwise-or of the events that should
+ trigger the callback.
+
+ The optional data argument can be used to store any POD
+ user data that doesn't exceed 8 bytes in size and doesn't require
+ alignment greater than unsigned long long
. For
+ example, we could store an old value of a flag or a counter
+ that needs to be restored in case of a roll back.
+
+ The optional state
argument can be used to
+ indicate that the callback has been unregistered because
+ the transaction was finalized. In this case the transaction
+ automatically resets the passed pointer to 0. This is
+ primarily useful if we are interested in only one of
+ the events (commit or rollback).
+
+ The unregister()
function unregisters a previously
+ registered callback. If the number of registered callbacks is
+ large, then this can be a slow operation. Generally, the callback
+ mechanism is optimized for cases where the callbacks stay
+ registered until the transaction is finalized.
+
+ Note also that you don't need to unregister a callback that has
+ been called or auto-reset using the state
argument
+ passed to register_()
. This function does nothing
+ if the key is not found.
+
+ When the callback is called, it is passed the event that
+ triggered it, as well as the key
and
+ data
values that were passed to the
+ register_()
function. Note also that the order
+ in which the callbacks are called is unspecified. The rollback
+ event can be triggered by an exception. In this case, if the
+ callback throws, the program will be terminated.
+
+ The following example shows how we can use transaction
+ callbacks together with database operation callbacks
+ (Section 12.1.7, "callback
")
+ to manage the object's "dirty" flag.
+
+
+#include <odb/callback.hxx>
+#include <odb/transaction.hxx>
+
+#pragma db object callback(update)
+class object
+{
+ ...
+
+ #pragma db transient
+ mutable bool dirty_;
+
+ // Non-NULL value indicates that we are registered
+ // with this transaction.
+ //
+ #pragma db transient
+ mutable odb::transaction* tran_;
+
+ void
+ update (odb::callback_event e, odb::database&) const
+ {
+ using namespace odb::core;
+
+ if (e == callback_event::post_update)
+ return;
+
+ // Mark the object as clean again but register a
+ // transaction callback in case the update is rolled
+ // back.
+ //
+ tran_ = &transaction::current ();
+ tran_->register_ (&rollback,
+ const_cast<object*> (this),
+ transaction::event_rollback,
+ 0,
+ &tran_);
+ dirty_ = false;
+ }
+
+ static void
+ rollback (unsigned short, void* key, unsigned long long)
+ {
+ // Restore the dirty flag since the changes have been
+ // rolled back.
+ //
+ object& o (*static_cast<object*> (key));
+ o.dirty_ = true;
+ }
+
+ ~object ()
+ {
+ // Unregister the callback if we are going away before
+ // the transaction.
+ //
+ if (tran_ != 0)
+ tran_->unregister (this);
+ }
+};
+
+
+
@@ -13896,12 +14072,12 @@ class person
II consists of the following chapters.
@@ -13909,7 +14085,7 @@ class person
-
+
Some applications may need to access multiple database systems, either
simultaneously or one at a time. For example, an application may
@@ -13970,7 +14146,7 @@ class person
separate libraries and loaded dynamically by the application. The
disadvantages of dynamic support are slight overhead and certain
limitations in functionality compared to static support (see
- Section 13.2, "Dynamic Multi-Database Support"
+ Section 14.2, "Dynamic Multi-Database Support"
for details). As a result, dynamic multi-database support is most
suitable to situations where we need the same code to
work with a range of database systems. For example, if your
@@ -14100,7 +14276,7 @@ odb --odb-file-suffix common:-odb-common ...
support in more detail.
-
+
With static multi-database support, instead of including
person-odb.hxx
, application source code has
@@ -14272,7 +14448,7 @@ odb -m static -d common -d pgsql -d sqlite --default-database pgsql ...
support is enabled, then the common (dynamic) interface is always
made the default database.
-
+
With dynamic multi-database support, application source code only
needs to include the person-odb.hxx
header file, just
@@ -14443,7 +14619,7 @@ namespace odb
expression). Every odb::<db>::query
class provides
such a translation constructor.
-
+
With dynamic multi-database support, the generated database support
code automatically registers itself with the function tables that
@@ -14621,7 +14797,7 @@ person.hxx
-
+
To generate support code for the MySQL database you will need
to pass the "--database mysql
"
@@ -14630,7 +14806,7 @@ person.hxx
library (libodb-mysql
). All MySQL-specific ODB
classes are defined in the odb::mysql
namespace.
-
+
The following table summarizes the default mapping between basic
C++ value types and MySQL database types. This mapping can be
@@ -14823,7 +14999,7 @@ class object
Section 12.7, "Database Type Mapping
Pragmas".
-
+
The MySQL database
class has the following
interface:
@@ -14983,7 +15159,7 @@ namespace odb
This constructor throws the odb::mysql::cli_exception
exception if the MySQL option values are missing or invalid.
- See section Section 14.4, "MySQL Exceptions"
+ See section Section 15.4, "MySQL Exceptions"
for more information on this exception.
The static print_usage()
function prints the list of options
@@ -15002,10 +15178,10 @@ namespace odb
The connection()
function returns a pointer to the
MySQL database connection encapsulated by the
odb::mysql::connection
class. For more information
- on mysql::connection
, refer to Section
- 14.3, "MySQL Connection and Connection Factory".
+ on mysql::connection
, refer to Section
+ 15.3, "MySQL Connection and Connection Factory".
-
+
The mysql::connection
class has the following interface:
@@ -15197,7 +15373,7 @@ main (int argc, char* argv[])
}
-
+
The MySQL ODB runtime library defines the following MySQL-specific
exceptions:
@@ -15249,12 +15425,12 @@ namespace odb
what()
function returns a human-readable description
of an error.
-
+
The following sections describe MySQL-specific limitations imposed
by the current MySQL and ODB runtime versions.
-
+
ODB relies on standard SQL behavior which requires that foreign
key constraints checking is deferred until the transaction is
@@ -15265,7 +15441,7 @@ namespace odb
foreign key definitions commented out. They are retained only
for documentation.
-
+
When the index
pragma (Section 12.6,
"Index Definition Pragmas") is used to define a MySQL index,
@@ -15294,7 +15470,7 @@ class object
-
+
To generate support code for the SQLite database you will need
to pass the "--database sqlite
"
@@ -15303,7 +15479,7 @@ class object
library (libodb-sqlite
). All SQLite-specific ODB
classes are defined in the odb::sqlite
namespace.
-
+
The following table summarizes the default mapping between basic
C++ value types and SQLite database types. This mapping can be
@@ -15481,7 +15657,7 @@ class object
Section 12.7, "Database Type Mapping
Pragmas".
-
+
The SQLite database
class has the following
interface:
@@ -15554,7 +15730,7 @@ namespace odb
values, refer to the sqlite3_open_v2()
function description
in the SQLite C API documentation. The foreign_keys
argument specifies whether foreign key constraints checking
- should be enabled. See Section 15.5.3,
+ should be enabled. See Section 16.5.3,
"Foreign Key Constraints" for more information on foreign
keys. The vfs
argument specifies the SQLite
virtual file system module that should be used to access the
@@ -15610,7 +15786,7 @@ auto_ptr<odb::database> db (
The third constructor throws the odb::sqlite::cli_exception
exception if the SQLite option values are missing or invalid.
- See Section 15.4, "SQLite Exceptions"
+ See Section 16.4, "SQLite Exceptions"
for more information on this exception.
The static print_usage()
function prints the list of options
@@ -15639,10 +15815,10 @@ auto_ptr<odb::database> db (
The connection()
function returns a pointer to the
SQLite database connection encapsulated by the
odb::sqlite::connection
class. For more information
- on sqlite::connection
, refer to Section
- 15.3, "SQLite Connection and Connection Factory".
+ on sqlite::connection
, refer to Section
+ 16.3, "SQLite Connection and Connection Factory".
-
+
The sqlite::connection
class has the following interface:
@@ -15687,7 +15863,7 @@ namespace odb
functions allow us to start an immediate and an exclusive SQLite
transaction on the connection, respectively. Their semantics are
equivalent to the corresponding functions defined in the
- sqlite::database
class (Section 15.2,
+ sqlite::database
class (Section 16.2,
"SQLite Database Class"). The handle()
accessor
returns the SQLite handle corresponding to the connection.
@@ -15887,7 +16063,7 @@ main (int argc, char* argv[])
}
-
+
The SQLite ODB runtime library defines the following SQLite-specific
exceptions:
@@ -15940,12 +16116,12 @@ namespace odb
of an error.
-
+
The following sections describe SQLite-specific limitations imposed by
the current SQLite and ODB runtime versions.
-
+
SQLite ODB runtime implementation does not perform query result caching
(Section 4.4, "Query Result") even when explicitly
@@ -15960,7 +16136,7 @@ namespace odb
thrown. Future versions of the SQLite ODB runtime library may add support
for result caching.
-
+
Due to SQLite API limitations, every automatically assigned object id
(Section 12.4.2, "auto
") should have
@@ -15986,7 +16162,7 @@ class person
};
-
+
By default the SQLite ODB runtime enables foreign key constraints
checking (PRAGMA foreign_keys=ON
). You can disable foreign
@@ -16050,7 +16226,7 @@ CREATE TABLE Employee (
-
+
Due to the granularity of the SQLite error codes, it is impossible
to distinguish between the duplicate primary key and other constraint
@@ -16059,7 +16235,7 @@ CREATE TABLE Employee (
object_already_persistent
exception (Section
3.14, "ODB Exceptions").
-
+
As discussed in Section 4.3, "Executing a Query", a
query instance that does not have any by-reference parameters is
@@ -16068,7 +16244,7 @@ CREATE TABLE Employee (
functionality. Future versions of the library will remove this
limitation.
-
+
When the index
pragma (Section 12.6,
"Index Definition Pragmas") is used to define an SQLite index,
@@ -16097,7 +16273,7 @@ class object
-
+
To generate support code for the PostgreSQL database you will need
to pass the "--database pgsql
"
@@ -16111,7 +16287,7 @@ class object
of the messaging protocol version 3.0. For this reason, ODB supports
only PostgreSQL version 7.4 and later.
-
+
The following table summarizes the default mapping between basic
C++ value types and PostgreSQL database types. This mapping can be
@@ -16289,7 +16465,7 @@ class object
For more information, refer to Section 12.7,
"Database Type Mapping Pragmas".
-
+
The PostgreSQL database
class has the following
interface:
@@ -16409,7 +16585,7 @@ namespace odb
This constructor throws the odb::pgsql::cli_exception
exception if the PostgreSQL option values are missing or invalid.
- See section Section 16.4, "PostgreSQL Exceptions"
+ See section Section 17.4, "PostgreSQL Exceptions"
for more information on this exception.
The static print_usage()
function prints the list of options
@@ -16435,10 +16611,10 @@ namespace odb
The connection()
function returns a pointer to the
PostgreSQL database connection encapsulated by the
odb::pgsql::connection
class. For more information
- on pgsql::connection
, refer to Section
- 16.3, "PostgreSQL Connection and Connection Factory".
+ on pgsql::connection
, refer to Section
+ 17.3, "PostgreSQL Connection and Connection Factory".
-
+
The pgsql::connection
class has the following interface:
@@ -16619,7 +16795,7 @@ main (int argc, char* argv[])
}
-
+
The PostgreSQL ODB runtime library defines the following
PostgreSQL-specific exceptions:
@@ -16668,12 +16844,12 @@ namespace odb
what()
function returns a human-readable description
of an error.
-
+
The following sections describe PostgreSQL-specific limitations imposed
by the current PostgreSQL and ODB runtime versions.
-
+
The PostgreSQL ODB runtime implementation will always return a
cached query result (Section 4.4, "Query Result")
@@ -16681,7 +16857,7 @@ namespace odb
PostgreSQL client library (libpq
) which does not
support uncached (streaming) query results.
-
+
ODB relies on standard SQL behavior which requires that
foreign key constraints checking is deferred until the
@@ -16699,7 +16875,7 @@ CREATE TABLE Employee (
employer BIGINT REFERENCES Employer(id) INITIALLY DEFERRED);
-
+
Due to the granularity of the PostgreSQL error codes, it is impossible
to distinguish between the duplicate primary key and other unique
@@ -16708,7 +16884,7 @@ CREATE TABLE Employee (
errors to the object_already_persistent
exception
(Section 3.14, "ODB Exceptions").
-
+
ODB expects the PostgreSQL server to use integers as a binary
format for the date-time types, which is the default for most
@@ -16723,14 +16899,14 @@ CREATE TABLE Employee (
SHOW integer_datetimes
-
+
ODB does not currently natively support the PostgreSQL date-time types
with timezone information. However, these types can be accessed by
mapping them to one of the natively supported types, as discussed
in Section 12.7, "Database Type Mapping Pragmas".
-
+
Support for the PostgreSQL NUMERIC
type is limited
to providing a binary buffer containing the binary representation
@@ -16742,7 +16918,7 @@ SHOW integer_datetimes
Type Mapping Pragmas".
-
+
When the index
pragma (Section 12.6,
"Index Definition Pragmas") is used to define a PostgreSQL index,
@@ -16781,7 +16957,7 @@ class object
-
+
To generate support code for the Oracle database you will need
to pass the "--database oracle
"
@@ -16790,7 +16966,7 @@ class object
library (libodb-oracle
). All Oracle-specific ODB
classes are defined in the odb::oracle
namespace.
-
+
The following table summarizes the default mapping between basic
C++ value types and Oracle database types. This mapping can be
@@ -16965,7 +17141,7 @@ class object
Section 12.7, "Database Type Mapping
Pragmas".
-
+
The Oracle database
class encapsulates the OCI environment
handle as well as the database connection string and user credentials
@@ -17090,7 +17266,7 @@ namespace odb
This constructor throws the odb::oracle::cli_exception
exception if the Oracle option values are missing or invalid. See section
- Section 17.4, "Oracle Exceptions" for more
+ Section 18.4, "Oracle Exceptions" for more
information on this exception.
The static print_usage()
function prints the list of options
@@ -17140,10 +17316,10 @@ namespace odb
The connection()
function returns a pointer to the
Oracle database connection encapsulated by the
odb::oracle::connection
class. For more information
- on oracle::connection
, refer to Section
- 17.3, "Oracle Connection and Connection Factory".
+ on oracle::connection
, refer to Section
+ 18.3, "Oracle Connection and Connection Factory".
-
+
The oracle::connection
class has the following interface:
@@ -17345,7 +17521,7 @@ main (int argc, char* argv[])
}
-
+
The Oracle ODB runtime library defines the following
Oracle-specific exceptions:
@@ -17426,12 +17602,12 @@ namespace odb
condition. The what()
function returns a human-readable
description of an error.
-
+
The following sections describe Oracle-specific limitations imposed
by the current Oracle and ODB runtime versions.
-
+
Oracle limits the length of database identifiers (table, column, etc.,
names) to 30 characters. The ODB compiler automatically truncates
@@ -17476,7 +17652,7 @@ class long_class_name
};
-
+
Oracle ODB runtime implementation does not perform query result caching
(Section 4.4, "Query Result") even when explicitly
@@ -17491,7 +17667,7 @@ class long_class_name
always thrown. Future versions of the Oracle ODB runtime library
may add support for result caching.
-
+
ODB relies on standard SQL behavior which requires that
foreign key constraints checking is deferred until the
@@ -17510,7 +17686,7 @@ CREATE TABLE Employee (
DEFERRABLE INITIALLY DEFERRED);
-
+
Due to the granularity of the Oracle error codes, it is impossible
to distinguish between the duplicate primary key and other unique
@@ -17519,7 +17695,7 @@ CREATE TABLE Employee (
errors to the object_already_persistent
exception
(Section 3.14, "ODB Exceptions").
- The mssql::connection
class has the following interface:
@@ -18435,7 +18611,7 @@ main (int argc, char* argv[])
}
- 18.4 SQL Server Exceptions
+ 19.4 SQL Server Exceptions
The SQL Server ODB runtime library defines the following
SQL Server-specific exceptions:
@@ -18516,14 +18692,14 @@ namespace odb
The odb::mssql::long_data_reload
is thrown if an
attempt is made to re-load an object or view with long data as
part of a query result iteration. For more information, refer
- to Section 18.1, "SQL Server Type Mapping".
+ to Section 19.1, "SQL Server Type Mapping".
- 18.5 SQL Server Limitations
+ 19.5 SQL Server Limitations
The following sections describe SQL Server-specific limitations imposed
by the current SQL Server and ODB runtime versions.
- 18.5.1 Query Result Caching
+ 19.5.1 Query Result Caching
SQL Server ODB runtime implementation does not perform query result
caching (Section 4.4, "Query Result") even when
@@ -18538,7 +18714,7 @@ namespace odb
3.14, "ODB Exceptions") is always thrown. Future versions of the
SQL Server ODB runtime library may add support for result caching.
- 18.5.2 Foreign Key Constraints
+ 19.5.2 Foreign Key Constraints
ODB relies on standard SQL behavior which requires that foreign
key constraints checking is deferred until the transaction is
@@ -18547,7 +18723,7 @@ namespace odb
the ODB compiler for SQL Server have foreign key definitions
commented out. They are retained only for documentation.
- 18.5.3 Unique Constraint Violations
+ 19.5.3 Unique Constraint Violations
Due to the granularity of the ODBC error codes, it is impossible
to distinguish between the duplicate primary key and other unique
@@ -18556,7 +18732,7 @@ namespace odb
errors to the object_already_persistent
exception
(Section 3.14, "ODB Exceptions").
- 18.5.4 Multi-threaded Windows Applications
+ 19.5.4 Multi-threaded Windows Applications
Multi-threaded Windows applications must use the
_beginthread()
/_beginthreadex()
and
@@ -18565,7 +18741,7 @@ namespace odb
Win32 functions to start and terminate threads. This is a limitation of
the ODBC implementation on Windows.
- 18.5.5 Affected Row Count and DDL Statements
+ 19.5.5 Affected Row Count and DDL Statements
SQL Server always returns zero as the number of affected rows
for DDL statements. In particular, this means that the
@@ -18573,7 +18749,7 @@ namespace odb
"Executing Native SQL Statements") function will always
return zero for such statements.
- 18.5.6 Long Data and Auto Object Ids, ROWVERSION
+ 19.5.6 Long Data and Auto Object Ids, ROWVERSION
SQL Server 2005 has a bug that causes it to fail on an INSERT
or UPDATE
statement with the OUTPUT
clause
@@ -18583,7 +18759,7 @@ namespace odb
by the database::persist()
or database::update()
function when used on an object that contains long data and has an
automatically assigned object id or uses ROWVERSION
-based
- optimistic concurrency (Section 18.1.1,
+ optimistic concurrency (Section 19.1.1,
"ROWVERSION
Support"). The error message reads "This
operation conflicts with another pending operation on this transaction.
The operation failed."
@@ -18600,7 +18776,7 @@ namespace odb
objects that use ROWVERSION
for optimistic concurrency
and containing long data.
- 18.5.7 Long Data and By-Value Accessors/Modifiers
+ 19.5.7 Long Data and By-Value Accessors/Modifiers
As discussed in Section 12.4.5,
"get
/set
/access
", by-value
@@ -18610,7 +18786,7 @@ namespace odb
by-reference accessors and modifiers should be used for these data
types.
- 18.6 SQL Server Index Definitions
+ 19.6 SQL Server Index Definitions
When the index
pragma (Section 12.6,
"Index Definition Pragmas") is used to define an SQL Server index,
@@ -18647,9 +18823,9 @@ class object
and libraries. It consists of the following chapters.
@@ -18657,7 +18833,7 @@ class object
- 19 Profiles Introduction
+ 20 Profiles Introduction
ODB profiles are a generic mechanism for integrating ODB with
widely-used C++ frameworks and libraries. A profile provides glue
@@ -18711,7 +18887,7 @@ odb --profile boost/date-time ...
- 20 Boost Profile
+ 21 Boost Profile
The ODB profile implementation for Boost is provided by the
libodb-boost
library and consists of multiple sub-profiles
@@ -18736,7 +18912,7 @@ odb --profile boost/date-time ...
that can be thrown by the Boost sub-profiles are described in the
following sections.
- 20.1 Smart Pointers Library
+ 21.1 Smart Pointers Library
The smart-ptr
sub-profile provides persistence
support for a subset of smart pointers from the Boost
@@ -18806,7 +18982,7 @@ class employee
this behavior, add the --default-pointer
option specifying
the alternative pointer type after the --profile
option.
- 20.2 Unordered Containers Library
+ 21.2 Unordered Containers Library
The unordered
sub-profile provides persistence support for
the containers from the Boost unordered
library. To enable
@@ -18832,7 +19008,7 @@ class person
};
-
20.3 Multi-Index Container Library
+ 21.3 Multi-Index Container Library
The multi-index
sub-profile provides persistence support for
boost::multi_index_container
from the Boost Multi-Index
@@ -18917,7 +19093,7 @@ class person
};
-
20.4 Optional Library
+ 21.4 Optional Library
The optional
sub-profile provides persistence support for
the boost::optional
container from the Boost
@@ -18949,7 +19125,7 @@ class person
this profile is used, the NULL
values are automatically
enabled for data members of the boost::optional
type.
- 20.5 Date Time Library
+ 21.5 Date Time Library
The date-time
sub-profile provides persistence support for a
subset of types from the Boost date_time
library. It is
@@ -19022,7 +19198,7 @@ namespace odb
exceptions are thrown are database system dependent and are discussed in
more detail in the following sub-sections.
- 20.5.1 MySQL Database Type Mapping
+ 21.5.1 MySQL Database Type Mapping
The following table summarizes the default mapping between the currently
supported Boost date_time
types and the MySQL database
@@ -19083,7 +19259,7 @@ class person
the out_of_range
exception. Refer to the MySQL
documentation for more information on the MySQL data type ranges.
- 20.5.2 SQLite Database Type Mapping
+ 21.5.2 SQLite Database Type Mapping
The following table summarizes the default mapping between the currently
supported Boost date_time
types and the SQLite database
@@ -19161,7 +19337,7 @@ class person
will result in the out_of_range
exception.
- 20.5.3 PostgreSQL Database Type Mapping
+ 21.5.3 PostgreSQL Database Type Mapping
The following table summarizes the default mapping between the currently
supported Boost date_time
types and the PostgreSQL database
@@ -19212,7 +19388,7 @@ class person
result in the special_value
exception.
- 20.5.4 Oracle Database Type Mapping
+ 21.5.4 Oracle Database Type Mapping
The following table summarizes the default mapping between the currently
supported Boost date_time
types and the Oracle database
@@ -19274,7 +19450,7 @@ class person
the special_value
exception.
- 20.5.5 SQL Server Database Type Mapping
+ 21.5.5 SQL Server Database Type Mapping
The following table summarizes the default mapping between the currently
supported Boost date_time
types and the SQL Server database
@@ -19345,7 +19521,7 @@ class person
posix_time::time_duration
value out of this range will
result in the value_out_of_range
exception.
- 20.6 Uuid Library
+ 21.6 Uuid Library
The uuid
sub-profile provides persistence support for the
uuid
type from the Boost uuid
library. To
@@ -19377,7 +19553,7 @@ class object
};
-
20.6.1 MySQL Database Type Mapping
+ 21.6.1 MySQL Database Type Mapping
The following table summarizes the default mapping between the Boost
uuid
type and the MySQL database type.
@@ -19397,7 +19573,7 @@ class object
-