Home
Extending HCL OneDB™Beyond standard relational database objects, HCL OneDB™ can be extended to handle specialized data types, access methods, routines, and other objects. HCL OneDB™ includes many built-in extensions that are fully integrated in the database server. HCL OneDB™ also provides DataBlade® modules, which are packages of extended database objects for a particular purpose and that are installed separately from the database server. Alternatively, you can create your own user-defined objects for HCL OneDB™.
Creating extensionsYou can create user-defined data types, routines, access methods, and other database objects to suit your needs. You can use application programming interfaces to write user-defined routines and applications that access data in HCL OneDB™ databases.
DataBlade® Developers KitThe DataBlade® Developers Kit (DBDK) guides contain information about the tools you can use to develop and package DataBlade® modules, which extend the functionality of HCL OneDB™ databases.
DataBlade® Developers Kit User's GuideThe HCL OneDB™ DataBlade® Developers Kit Users Guide describes how to use OneDB® DataBlade® Developers Kit (DBDK) tools to develop and package DataBlade® modules.
Debugging and testing DataBlade® modules on UNIX™This section describes how to debug and perform functional tests for DataBlade® modules written in C for HCL OneDB™ on UNIX™.
Performing functional testsWhen you generate functional tests, BladeSmith creates a set of files that include shell scripts and SQL scripts for testing opaque data type support routines, user-defined routines, and cast support functions. By default, these files are created in the functest subdirectory of the directory containing the BladeSmith project file.
Functional test overviewFunctional tests include SQL scripts and shell scripts that execute the SQL scripts and determine the results. The shell scripts build test tables in a database, run the SQL test scripts, and then drop the test tables from the database.

Functional test overview

Functional tests include SQL scripts and shell scripts that execute the SQL scripts and determine the results. The shell scripts build test tables in a database, run the SQL test scripts, and then drop the test tables from the database.

You can create custom shell scripts to run additional tests or initialization scripts. The generated scripts include calls to your custom scripts.

Shell scripts execute SQL scripts by using DB-Access. The results from the SQL statements are saved in .log files. When you first run functional tests, you must inspect the .log files and, if the results are correct, use the shell scripts to copy them to .req files.

When you execute functional tests after saving .req files, the shell script uses the UNIX™ diff command to compare the .log files to the .req files. The script prints the following messages:

test passed message if the .log and .req files match
test failed message if the files do not match
status unknown message when a .req file does not yet exist

Important: There are minor formatting differences between the UNIX and Windows™ versions of DB-Acess that can cause tests to indicate failure incorrectly.

Have feedback?
Google Analytics is used to store comments and ratings. To provide a comment or rating for a topic, click Accept All Cookies or Allow All in Cookie Preferences in the footer of this page.