From 07299aa3a0a840845c5d22b74af30aa0ce3ac9f1 Mon Sep 17 00:00:00 2001 From: Boris Kolpackov Date: Fri, 25 Jan 2013 14:32:06 +0200 Subject: Document new char[N] mapping --- doc/manual.xhtml | 791 ++++++++++++++++++++++++++++++++++++++++++------------- 1 file changed, 605 insertions(+), 186 deletions(-) (limited to 'doc') diff --git a/doc/manual.xhtml b/doc/manual.xhtml index 13b467a..ba4a75d 100644 --- a/doc/manual.xhtml +++ b/doc/manual.xhtml @@ -607,7 +607,14 @@ for consistency. 15MySQL Database - + + + @@ -626,7 +633,14 @@ for consistency. - + @@ -17216,26 +17471,101 @@ class object + + + + + +
15.1MySQL Type Mapping
15.1MySQL Type Mapping + + + +
15.1.1String Type Mapping
15.1.2Binary Type Mapping
+
15.2MySQL Database Class
15.3MySQL Connection and Connection Factory
15.4MySQL Exceptions
16SQLite Database - + + + @@ -649,7 +663,14 @@ for consistency. - + @@ -16537,21 +16721,49 @@ class object + + + + + +
16.1SQLite Type Mapping
16.1SQLite Type Mapping + + + +
16.1.1String Type Mapping
16.1.2Binary Type Mapping
+
16.2SQLite Database Class
16.3SQLite Connection and Connection Factory
16.4SQLite Exceptions
17PostgreSQL Database - + + + @@ -673,7 +694,14 @@ for consistency. - + @@ -15731,12 +15836,29 @@ class object + + + + + + + + + + + +
17.1PostgreSQL Type Mapping
17.1PostgreSQL Type Mapping + + + +
17.1.1String Type Mapping
17.1.2Binary Type and UUID Mapping
+
17.2PostgreSQL Database Class
17.3PostgreSQL Connection and Connection Factory
17.4PostgreSQL Exceptions
18Oracle Database - + + + @@ -702,7 +730,10 @@ for consistency. @@ -11927,11 +11958,14 @@ class person

The null and not_null (Section 12.4.6, "null/not_null") specifiers - can be used to control the NULL semantics of a data member.

+ can be used to control the NULL semantics of a data member. It is + also possible to specify the database type on the per-type instead + of the per-member basis using the value type + specifier (Section 12.3.1, "type").

12.4.4 id_type

-

The type specifier specifies the native database type +

The id_type specifier specifies the native database type that should be used for the data member when it is part of an object identifier. This specifier only makes sense when applied to a member of a composite value type that is used for both id and @@ -14975,7 +15009,7 @@ person.hxx

- + @@ -15056,8 +15090,19 @@ person.hxx + + + + + +
18.1Oracle Type Mapping
18.1Oracle Type Mapping + + + +
18.1.1String Type Mapping
18.1.2Binary Type Mapping
+
18.2Oracle Database Class
18.3Oracle Connection and Connection Factory
18.4Oracle Exceptions
19.1SQL Server Type Mapping - + + + +
19.1.1ROWVERSION Support
19.1.1String Type Mapping
19.1.2Binary Type and UNIQUEIDENTIFIER Mapping
19.1.3ROWVERSION Mapping
19.1.4Long String and Binary Types
charTINYINTCHAR(1) NOT NULL
TEXT/VARCHAR(255) NOT NULL
char[N]VARCHAR(N-1)NOT NULL
+

It is possible to map the char C++ type to an integer + database type (for example, TINYINT) using the + db type pragma (Section 12.4.3, + "type").

+

Note that the std::string type is mapped differently depending on whether a member of this type is an object id or not. If the member is an object id, @@ -15065,14 +15110,94 @@ person.hxx to the VARCHAR(255) MySQL type. Otherwise, it is mapped to TEXT.

-

The MySQL ODB runtime library also provides support for mapping the - std::string type to the MySQL CHAR, - NCHAR, and NVARCHAR types, as well as for - mapping the std::vector<char>, +

Additionally, by default, C++ enumerations are automatically + mapped to a suitable MySQL type. Contiguous enumerations with + the zero first enumerator are mapped to the MySQL ENUM + type. All other enumerations are mapped to INT or + INT UNSIGNED. In both cases the default NULL + semantics is NOT NULL. For example:

+ + 
+enum color {red, green, blue};
+enum taste
+{
+  bitter = 1, // Non-zero first enumerator.
+  sweet,
+  sour = 4,   // Non-contiguous.
+  salty
+};
+
+#pragma db object
+class object
+{
+  ...
+
+  color color_; // Mapped to ENUM ('red', 'green', 'blue') NOT NULL.
+  taste taste_; // Mapped to INT UNSIGNED NOT NULL.
+};
+
+ +

It is also possible to add support for additional MySQL types, + such as geospatial types. For more information, refer to + Section 12.7, "Database Type Mapping + Pragmas".

+ +

15.1.1 String Type Mapping

+ +

The MySQL ODB runtime library provides support for mapping the + std::string, char[N], and + std::array<char, N> types to the MySQL CHAR, + VARCHAR, TEXT, NCHAR, and + NVARCHAR types. However, these mappings are not enabled + by default (in particular, by default, std::array will + be treated as a container). To enable the alternative mappings for + these types we need to specify the database type explicitly using + the db type pragma (Section + 12.4.3, "type"), for example:

+ + 
+#pragma db object
+class object
+{
+  ...
+
+  #pragma db type("CHAR(2)")
+  char state_[2];
+
+  #pragma db type("VARCHAR(128)")
+  std::string name_;
+};
+
+ +

Alternatively, this can be done on the per-type basis, for example:

+ + 
+#pragma db value(std::string) type("VARCHAR(128)")
+
+#pragma db object
+class object
+{
+  ...
+
+  std::string name_; // Mapped to VARCHAR(128).
+};
+
+ +

The char[N] and std::array<char, N> values + may or may not be zero-terminated. When extracting such values from the + database, ODB will append the zero terminator if there is enough + space.

+ +

15.1.2 Binary Type Mapping

+ +

The MySQL ODB runtime library provides support for mapping the + std::vector<char>, std::vector<unsigned char>, char[N], unsigned char[N], - std::array<char, N>, and std::array<unsigned char, N> - types to the MySQL BLOB types. However, these mappings are not enabled + std::array<char, N>, and + std::array<unsigned char, N> + types to the MySQL BINARY, VARBINARY, + and BLOB types. However, these mappings are not enabled by default (in particular, by default, std::vector and std::array will be treated as containers). To enable the alternative mappings for these types we need to specify the database @@ -15086,9 +15211,6 @@ class object { ... - #pragma db type("CHAR(2)") - std::string state_; - #pragma db type("BLOB") std::vector<char> buf_; @@ -15112,38 +15234,21 @@ class object }; -

Additionally, by default, C++ enumerations are automatically - mapped to a suitable MySQL type. Contiguous enumerations with - the zero first enumerator are mapped to the MySQL ENUM - type. All other enumerations are mapped to INT or - INT UNSIGNED. In both cases the default NULL - semantics is NOT NULL. For example:

+

Note also that in native queries (Chapter 4, "Querying + the Database") char[N] and + std::array<char, N> parameters are by default passed + as a string rather than a binary. To pass such parameters as a binary, + we need to specify the database type explicitly in the + _val()/_ref() calls. Note also that we + don't need to do this for the integrated queries, for example:

-enum color {red, green, blue};
-enum taste
-{
-  bitter = 1, // Non-zero first enumerator.
-  sweet,
-  sour = 4,   // Non-contiguous.
-  salty
-};
+char u[16] = {...};
 
-#pragma db object
-class object
-{
-  ...
-
-  color color_; // Mapped to ENUM ('red', 'green', 'blue') NOT NULL.
-  taste taste_; // Mapped to INT UNSIGNED NOT NULL.
-};
+db.query<object> ("uuid = " + query::_val<odb::mysql::id_blob> (u));
+db.query<object> (query::uuid == query::_ref (u));
-

It is also possible to add support for additional MySQL types, - such as geospatial types. For more information, refer to - Section 12.7, "Database Type Mapping - Pragmas".

-

15.2 MySQL Database Class

The MySQL database class has the following @@ -15648,7 +15753,7 @@ class object

charINTEGERTEXT NOT NULL
char[N]TEXTNOT NULL
std::wstring (Windows only) TEXT NOT NULL
wchar_t[N] (Windows only)TEXTNOT NULL
+

It is possible to map the char C++ type to the + INTEGER SQLite type (TINYINT) using + the db type pragma (Section + 12.4.3, "type").

+

SQLite represents the NaN FLOAT value as a NULL value. As a result, columns of the float and double types are by default @@ -15745,18 +15867,80 @@ class object db not_null pragma (Section 12.4.6, "null/not_null").

-

The SQLite ODB runtime library also provides support for mapping the +

Additionally, by default, C++ enumerations are automatically mapped to + the SQLite INTEGER type with the default NULL + semantics being NOT NULL.

+ +

Note also that SQLite only operates with signed integers and the largest + value that an SQLite database can store is a signed 64-bit integer. As + a result, greater unsigned long and + unsigned long long values will be represented in + the database as negative values.

+ +

It is also possible to add support for additional SQLite types, + such as NUMERIC. For more information, refer to + Section 12.7, "Database Type Mapping + Pragmas".

+ +

16.1.1 String Type Mapping

+ +

The SQLite ODB runtime library provides support for mapping the + std::array<char, N> and, on Windows, + std::array<wchar_t, N> types to the SQLite + TEXT type. However, this mapping is not enabled by + default (in particular, by default, std::array will + be treated as a container). To enable the alternative mapping for + this type we need to specify the database type explicitly using + the db type pragma (Section + 12.4.3, "type"), for example:

+ + 
+#pragma db object
+class object
+{
+  ...
+
+  #pragma db type("TEXT")
+  std::array<char, 128> name_;
+};
+
+ +

Alternatively, this can be done on the per-type basis, for example:

+ + 
+typedef std::array<char, 128> name_type;
+#pragma db value(name_type) type("TEXT")
+
+#pragma db object
+class object
+{
+  ...
+
+  name_type name_; // Mapped to TEXT.
+};
+
+ +

The char[N], std::array<char, N>, + wchar_t[N], and std::array<wchar_t, N> + values may or may not be zero-terminated. When extracting such values + from the database, ODB will append the zero terminator if there is + enough space.

+ +

16.1.2 Binary Type Mapping

+ +

The SQLite ODB runtime library provides support for mapping the std::vector<char>, std::vector<unsigned char>, char[N], unsigned char[N], - std::array<char, N>, and std::array<unsigned char, N> - types to the SQLite BLOB type. However, this mapping is not enabled - by default (in particular, by default, std::vector and - std::array will be treated as containers). To enable the - BLOB mapping for these types we need to specify the database type - explicitly using the db type pragma - (Section 12.4.3, "type"), for - example:

+ std::array<char, N>, and + std::array<unsigned char, N> + types to the SQLite BLOB type. However, these mappings + are not enabled by default (in particular, by default, + std::vector and std::array will be treated + as containers). To enable the alternative mappings for these types + we need to specify the database type explicitly using the + db type pragma (Section 12.4.3, + "type"), for example:

 #pragma db object
@@ -15787,20 +15971,20 @@ class object
 };
-

Additionally, by default, C++ enumerations are automatically mapped to - the SQLite INTEGER type with the default NULL - semantics being NOT NULL.

+

Note also that in native queries (Chapter 4, "Querying + the Database") char[N] and + std::array<char, N> parameters are by default passed + as a string rather than a binary. To pass such parameters as a binary, + we need to specify the database type explicitly in the + _val()/_ref() calls. Note also that we + don't need to do this for the integrated queries, for example:

-

Note also that SQLite only operates with signed integers and the largest - value that an SQLite database can store is a signed 64-bit integer. As - a result, greater unsigned long and - unsigned long long values will be represented in - the database as negative values.

+ 
+char u[16] = {...};
 
-  
It is also possible to add support for additional SQLite types,
-     such as NUMERIC. For more information, refer to
-     Section 12.7, "Database Type Mapping
-     Pragmas".

+db.query<object> ("uuid = " + query::_val<odb::sqlite::id_blob> (u));
+db.query<object> (query::uuid == query::_ref (u));
+

16.2 SQLite Database Class

@@ -16456,7 +16640,7 @@ class object
charSMALLINTCHAR(1) NOT NULL
TEXT NOT NULL
char[N]VARCHAR(N-1)NOT NULL
-

The PostgreSQL ODB runtime library also provides support for mapping - the std::string type to the PostgreSQL CHAR - and VARCHAR types as well as the char[16] - array to the PostgreSQL UUID type. There is also support - for mapping the std::vector<char>, - std::vector<unsigned char>, - char[N], unsigned char[N], - std::array<char, N>, and std::array<unsigned char, N> - types to the PostgreSQL BYTEA type. However, these mappings - are not enabled by default (in particular, by default, - std::vector and std::array will be treated - as containers). To enable the alternative mappings for these types we - need to specify the database type explicitly using the +

It is possible to map the char C++ type to an integer + database type (for example, SMALLINT) using the + db type pragma (Section 12.4.3, + "type").

+ +

Additionally, by default, C++ enumerations are automatically + mapped to INTEGER with the default NULL + semantics being NOT NULL.

+ +

Note also that because PostgreSQL does not support unsigned integers, + the unsigned short, unsigned int, and + unsigned long/unsigned long long C++ types + are by default mapped to the SMALLINT, INTEGER, + and BIGINT PostgreSQL types, respectively. The sign bit + of the value stored by the database for these types will contain + the most significant bit of the actual unsigned value being + persisted.

+ +

It is also possible to add support for additional PostgreSQL types, + such as NUMERIC, geometry types, XML, + JSON, enumeration types, composite types, arrays, + geospatial types, and the key-value store (HSTORE). + For more information, refer to Section 12.7, + "Database Type Mapping Pragmas".

+ +

17.1.1 String Type Mapping

+ +

The PostgreSQL ODB runtime library provides support for mapping the + std::string, char[N], and + std::array<char, N> types to the PostgreSQL + CHAR, VARCHAR, and TEXT + types. However, these mappings are not enabled by default (in + particular, by default, std::array will be treated + as a container). To enable the alternative mappings for these + types we need to specify the database type explicitly using the db type pragma (Section 12.4.3, "type"), for example:

@@ -16562,7 +16774,54 @@ class object ... #pragma db type("CHAR(2)") - std::string state_; + char state_[2]; + + #pragma db type("VARCHAR(128)") + std::string name_; +}; + + +

Alternatively, this can be done on the per-type basis, for example:

+ + 
+#pragma db value(std::string) type("VARCHAR(128)")
+
+#pragma db object
+class object
+{
+  ...
+
+  std::string name_; // Mapped to VARCHAR(128).
+};
+
+ +

The char[N] and std::array<char, N> values + may or may not be zero-terminated. When extracting such values from the + database, ODB will append the zero terminator if there is enough + space.

+ +

17.1.2 Binary Type and UUID Mapping

+ +

The PostgreSQL ODB runtime library provides support for mapping the + std::vector<char>, + std::vector<unsigned char>, + char[N], unsigned char[N], + std::array<char, N>, and + std::array<unsigned char, N> types to the PostgreSQL + BYTEA type. There is also support for mapping the + char[16] array to the PostgreSQL UUID type. + However, these mappings are not enabled by default (in particular, by + default, std::vector and std::array will be + treated as containers). To enable the alternative mappings for these + types we need to specify the database type explicitly using the + db type pragma (Section 12.4.3, + "type"), for example:

+ + 
+#pragma db object
+class object
+{
+  ...
 
   #pragma db type("UUID")
   char uuid_[16];
@@ -16590,25 +16849,21 @@ class object
 };
-

Additionally, by default, C++ enumerations are automatically - mapped to INTEGER with the default NULL - semantics being NOT NULL.

+

Note also that in native queries (Chapter 4, "Querying + the Database") char[N] and + std::array<char, N> parameters are by default passed + as a string rather than a binary. To pass such parameters as a binary, + we need to specify the database type explicitly in the + _val()/_ref() calls. Note also that we + don't need to do this for the integrated queries, for example:

-

Note also that because PostgreSQL does not support unsigned integers, - the unsigned short, unsigned int, and - unsigned long/unsigned long long C++ types - are by default mapped to the SMALLINT, INTEGER, - and BIGINT PostgreSQL types, respectively. The sign bit - of the value stored by the database for these types will contain - the most significant bit of the actual unsigned value being - persisted.

+ 
+char u[16] = {...};
 
-  
It is also possible to add support for additional PostgreSQL types,
-     such as NUMERIC, geometry types, XML,
-     JSON, enumeration types, composite types, arrays,
-     geospatial types, and the key-value store (HSTORE).
-     For more information, refer to Section 12.7,
-     "Database Type Mapping Pragmas".

+db.query<object> ("uuid = " + query::_val<odb::pgsql::id_uuid> (u));
+db.query<object> ("buf = " + query::_val<odb::pgsql::id_bytea> (u));
+db.query<object> (query::uuid == query::_ref (u));
+

17.2 PostgreSQL Database Class

@@ -17135,7 +17390,7 @@ class object
charNUMBER(3)CHAR(1) NOT NULL
VARCHAR2(512) NULL
char[N]VARCHAR2(N-1)NULL
+

It is possible to map the char C++ type to an integer + database type (for example, NUMBER(3)) using the + db type pragma (Section 12.4.3, + "type").

+

In Oracle empty VARCHAR2 and NVARCHAR2 strings are represented as a NULL value. As a result, - columns of the std::string type are by default declared - as NULL except for primary key columns. However, you - can override this by explicitly declaring them as NOT NULL - with the db not_null pragma (Section + columns of the std::string and char[N] + types are by default declared as NULL except for + primary key columns. However, you can override this by explicitly + declaring such columns as NOT NULL with the + db not_null pragma (Section 12.4.6, "null/not_null"). This also means that for object ids that are mapped to these Oracle types, an empty string is an invalid value.

-

The Oracle ODB runtime library also provides support for mapping the - std::string type to the Oracle CHAR, - NCHAR, NVARCHAR2, CLOB and - NCLOB types, as well as for mapping the +

Additionally, by default, C++ enumerations are automatically + mapped to NUMBER(10) with the default NULL + semantics being NOT NULL.

+ +

It is also possible to add support for additional Oracle types, + such as XML, geospatial types, user-defined types, + and collections (arrays, table types). For more information, refer to + Section 12.7, "Database Type Mapping + Pragmas".

+ +

18.1.1 String Type Mapping

+ +

The Oracle ODB runtime library provides support for mapping the + std::string, char[N], and + std::array<char, N> types to the Oracle CHAR, + VARCHAR2, CLOB, NCHAR, + NVARCHAR2, and NCLOB types. However, + these mappings are not enabled by default (in particular, by + default, std::array will be treated as a container). + To enable the alternative mappings for these types we need to + specify the database type explicitly using the db type + pragma (Section 12.4.3, "type"), + for example:

+ + 
+#pragma db object
+class object
+{
+  ...
+
+  #pragma db type ("CHAR(2)")
+  char state_[2];
+
+  #pragma db type ("VARCHAR(128)") null
+  std::string name_;
+
+  #pragma db type ("CLOB")
+  std::string text_;
+};
+
+ +

Alternatively, this can be done on the per-type basis, for example:

+ + 
+#pragma db value(std::string) type("VARCHAR(128)") null
+
+#pragma db object
+class object
+{
+  ...
+
+  std::string name_; // Mapped to VARCHAR(128).
+
+  #pragma db type ("CLOB")
+  std::string text_; // Mapped to CLOB.
+};
+
+ +

The char[N] and std::array<char, N> values + may or may not be zero-terminated. When extracting such values from the + database, ODB will append the zero terminator if there is enough + space.

+ +

18.1.2 Binary Type Mapping

+ +

The Oracle ODB runtime library provides support for mapping the std::vector<char>, std::vector<unsigned char>, char[N], unsigned char[N], - std::array<char, N>, and std::array<unsigned char, N> + std::array<char, N>, and + std::array<unsigned char, N> types to the Oracle BLOB and RAW types. However, these mappings are not enabled by default (in particular, by default, std::vector and std::array will be @@ -17250,9 +17580,6 @@ class object { ... - #pragma db type ("CLOB") - std::string str_; - #pragma db type("BLOB") std::vector<char> buf_; @@ -17276,15 +17603,20 @@ class object }; -

Additionally, by default, C++ enumerations are automatically - mapped to NUMBER(10) with the default NULL - semantics being NOT NULL.

+

Note also that in native queries (Chapter 4, "Querying + the Database") char[N] and + std::array<char, N> parameters are by default passed + as a string rather than a binary. To pass such parameters as a binary, + we need to specify the database type explicitly in the + _val()/_ref() calls. Note also that we + don't need to do this for the integrated queries, for example:

-

It is also possible to add support for additional Oracle types, - such as XML, geospatial types, user-defined types, - and collections (arrays, table types). For more information, refer to - Section 12.7, "Database Type Mapping - Pragmas".

+ 
+char u[16] = {...};
+
+db.query<object> ("uuid = " + query::_val<odb::oracle::id_raw> (u));
+db.query<object> (query::uuid == query::_ref (u));
+

18.2 Oracle Database Class

@@ -17957,7 +18289,7 @@ class object char - TINYINT + CHAR(1) NOT NULL @@ -18040,12 +18372,24 @@ class object + char[N] + VARCHAR(N-1) + NOT NULL + + + std::wstring NVARCHAR(512)/NVARCHAR(256) NOT NULL + wchar_t[N] + NVARCHAR(N-1) + NOT NULL + + + GUID UNIQUEIDENTIFIER NOT NULL @@ -18053,6 +18397,11 @@ class object +

It is possible to map the char C++ type to an integer + database type (for example, TINYINT) using the + db type pragma (Section 12.4.3, + "type").

+

Note that the std::string and std::wstring types are mapped differently depending on whether a member of one of these types is an object id or not. If the member is an object id, @@ -18064,24 +18413,98 @@ class object always change this mapping using the db type pragma (Section 12.4.3, "type").

+

Additionally, by default, C++ enumerations are automatically + mapped to INT with the default NULL + semantics being NOT NULL.

+ +

Note also that because SQL Server does not support unsigned integers, + the unsigned short, unsigned int, and + unsigned long/unsigned long long C++ types + are by default mapped to the SMALLINT, INT, + and BIGINT SQL Server types, respectively. The sign bit + of the value stored by the database for these types will contain + the most significant bit of the actual unsigned value being + persisted. Similarly, because there is no signed version of the + TINYINT SQL Server type, by default, the + signed char C++ type is mapped to TINYINT. + As a result, the most significant bit of the value stored by the + database for this type will contain the sign bit of the actual + signed value being persisted.

+ +

It is also possible to add support for additional SQL Server types, + such as geospatial types, XML, and user-defined types. + For more information, refer to Section 12.7, "Database + Type Mapping Pragmas".

+ +

19.1.1 String Type Mapping

+ +

The SQL Server ODB runtime library provides support for mapping the + std::string, char[N], and + std::array<char, N> types to the SQL Server + CHAR, VARCHAR, and TEXT + types as well as the std::wstring, wchar_t[N], + and std::array<wchar_t, N> types to NCHAR, + NVARCHAR, and NTEXT. However, these mappings + are not enabled by default (in particular, by default, + std::array will be treated as a container). To enable the + alternative mappings for these types we need to specify the database + type explicitly using the db type pragma + (Section 12.4.3, "type"), for + example:

+ + 
+#pragma db object
+class object
+{
+  ...
+
+  #pragma db type ("CHAR(2)")
+  char state_[2];
+
+  #pragma db type ("NVARCHAR(max)")
+  std::wstring text_;
+};
+
+ +

Alternatively, this can be done on the per-type basis, for example:

+ + 
+#pragma db value(std::wstring) type("NVARCHAR(max)")
+
+#pragma db object
+class object
+{
+  ...
+
+  std::wstring text_; // Mapped to NVARCHAR(max).
+};
+
+ +

The char[N], std::array<char, N>, + wchar_t[N], and std::array<wchar_t, N> + values may or may not be zero-terminated. When extracting such values + from the database, ODB will append the zero terminator if there is + enough space.

+ +

See also Section 19.1.4, "Long String and Binary + Types" for certain limitations of long string types.

+ +

19.1.2 Binary Type and UNIQUEIDENTIFIER Mapping

+

The SQL Server ODB runtime library also provides support for mapping the - std::string type to the SQL Server CHAR and - TEXT types as well as std::wstring - to NCHAR and NTEXT. There is also support - for mapping the char[16] array to the SQL Server - UNIQUEIDENTIFIER type as well as the std::vector<char>, std::vector<unsigned char>, char[N], unsigned char[N], std::array<char, N>, and std::array<unsigned char, N> types to the SQL Server BINARY, VARBINARY, and - IMAGE types. However, these mappings are not enabled - by default (in particular, by default, std::vector and - std::array will be treated as containers). To enable the - alternative mappings for these types we need to specify the database - type explicitly using the db type pragma - (Section 12.4.3, "type"), for - example:

+ IMAGE types. There is also support for mapping the + char[16] array to the SQL Server UNIQUEIDENTIFIER + type. However, these mappings are not enabled by default (in particular, + by default, std::vector and std::array will + be treated as containers). To enable the alternative mappings for these + types we need to specify the database type explicitly using the + db type pragma (Section 12.4.3, + "type"), for example:

 #pragma db object
@@ -18089,9 +18512,6 @@ class object
 {
   ...
 
-  #pragma db type ("CHAR(5)")
-  std::string str_;
-
   #pragma db type("UNIQUEIDENTIFIER")
   char uuid_[16];
 
@@ -18118,9 +18538,56 @@ class object
 };
-

Additionally, by default, C++ enumerations are automatically - mapped to INT with the default NULL - semantics being NOT NULL.

+

Note also that in native queries (Chapter 4, "Querying + the Database") char[N] and + std::array<char, N> parameters are by default passed + as a string rather than a binary. To pass such parameters as a binary, + we need to specify the database type explicitly in the + _val()/_ref() calls. Note also that we + don't need to do this for the integrated queries, for example:

+ + 
+char u[16] = {...};
+
+db.query<object> ("uuid = " + query::_val<odb::mssql::id_binary> (u));
+db.query<object> (
+  "uuid = " + query::_val<odb::mssql::id_uniqueidentifier> (u));
+db.query<object> (query::uuid == query::_ref (u));
+
+ +

See also Section 19.1.4, "Long String and Binary + Types" for certain limitations of long binary types.

+ +

19.1.3 ROWVERSION Mapping

+ +

ROWVERSION is a special SQL Server data type that is + automatically incremented by the database server whenever a row + is inserted or updated. As such, it is normally used to implement + optimistic concurrency and ODB provides support for using + ROWVERSION instead of the more portable approach + for optimistic concurrency (Chapter 11, "Optimistic + Concurrency").

+ +

ROWVERSION is a 64-bit value which is mapped by ODB + to unsigned long long. As a result, to use + ROWVERSION for optimistic concurrency we need to + make sure that the version column is of the unsigned long + long type. We also need to explicitly specify that it + should be mapped to the ROWVERSION data type. For + example:

+ + 
+#pragma db object optimistic
+class person
+{
+  ...
+
+  #pragma db version type("ROWVERSION")
+  unsigned long long version_;
+};
+
+ +

19.1.4 Long String and Binary Types

For SQL Server, ODB handles character, national character, and binary data in two different ways depending on its maximum length. @@ -18182,54 +18649,6 @@ t.commit (); members should come last both in the select-list of the native SQL query and the list of data members in the C++ class.

-

Note also that because SQL Server does not support unsigned integers, - the unsigned short, unsigned int, and - unsigned long/unsigned long long C++ types - are by default mapped to the SMALLINT, INT, - and BIGINT SQL Server types, respectively. The sign bit - of the value stored by the database for these types will contain - the most significant bit of the actual unsigned value being - persisted. Similarly, because there is no signed version of the - TINYINT SQL Server type, by default, char - and signed char C++ types are mapped to - TINYINT. As a result, the most significant bit of - the value stored by the database for these types will contain the - sign bit of the actual signed value being persisted.

- -

It is also possible to add support for additional SQL Server types, - such as geospatial types, XML, and user-defined types. - For more information, refer to Section 12.7, "Database - Type Mapping Pragmas".

- -

19.1.1 ROWVERSION Support

- -

ROWVERSION is a special SQL Server data type that is - automatically incremented by the database server whenever a row - is inserted or updated. As such, it is normally used to implement - optimistic concurrency and ODB provides support for using - ROWVERSION instead of the more portable approach - for optimistic concurrency (Chapter 11, "Optimistic - Concurrency").

- -

ROWVERSION is a 64-bit value which is mapped by ODB - to unsigned long long. As a result, to use - ROWVERSION for optimistic concurrency we need to - make sure that the version column is of the unsigned long - long type. We also need to explicitly specify that it - should be mapped to the ROWVERSION data type. For - example:

- - 
-#pragma db object optimistic
-class person
-{
-  ...
-
-  #pragma db version type("ROWVERSION")
-  unsigned long long version_;
-};
-
-

19.2 SQL Server Database Class

The SQL Server database class encapsulates the ODBC -- cgit v1.1