SOCI - beyond

Beyond SOCI

As the original name of the library (Simple Oracle Call Interface) clearly stated, SOCI is intended to be a simple library, targetting the majority of needs in regular C++ application. We do not claim that everything can be done with SOCI and it was never the intent of the library. What is important, though, is that the simplicity of the library does not prevent the client applications from reaching into the low-level specifics of each database backend in order to achieve special configuration or performance goals.

Most of the SOCI classes have the getBackEnd method, which returns the pointer to the actual backend object that implements the given functionality. The knowledge of the actual backend allows the client application to get access to all low-level details that are involved.

blob b(sql);

oracle_session_back_end * sessionBackEnd = static_cast<oracle_session_back_end *>(sql.get_back_end());
oracle_blob_back_end * blobBackEnd = static_cast<oracle_blob_back_end *>(b.get_back_end());

OCILobDisableBuffering(sessionBackEnd->svchp_, sessionBackEnd->errhp_, blobBackEnd->lobp_);

The above code creates the blob object and uses two calls to the get_back_end function (on both the session and the blob objects) to get access to the actual backend objects. Assuming that it is the "oracle" backend which is in use, the downcasts allow to access all relevant low-level handles and use them in the call to the OCILobDisableBuffering function. This way, the BLOB handle was configured in a way that the SOCI library alone would not allow.

rowid rid(sql); // sql is a session object
sql << "select oid from mytable where id = 7", into(rid);

postgresql_rowid_back_end * rbe = static_cast<postgresql_rowid_back_end *>(rid.get_back_end());

unsigned long oid = rbe->value_;

The above example retrieves the rowid ("something" that identifies the row in the table) from the table and uses the get_back_end function to extract the actual object that implements this functionality. Assuming that it is the "postgresql" backend which is in use, the downcast is performed to use the postgresql_rowid_back_end interface to get the actual OID value that is a physical, low-level implementation of row identifier on PostgreSQL databases.

In order for any of the above to compile, you have to explicitly #include the appropriate backend's header file.

Please see the header file related to the given backend to learn what low-level handles and descriptors are available.

Previous (Interfaces)

Next (Client reference)