The scope of this tutorial is to introduce you some of the CUBRID features regarding database stored procedures.

Overview

One of the most powerful CUBRID features is the built-in support for stored procedures. If you are not familiar with the concept of “stored procedures”, we recommend that you first read about it, before continuing further with this tutorial; one great place to start is, for example,  http://en.wikipedia.org/wiki/Stored_procedure.

Why use Stored Procedures?

There are many reasons why most of the databases, both commercial and open-source, implement support for stored procedures:

Do things which are not available in “plain” SQL. For example, using Java stored procedures you can:

• Get access to the file system
• Get access to web/web services
• Implement complex business logic
• …and, generally speaking, do whatever things you can do using a powerful development language like Java, for example.

Share the code/Share the features/Code reuse! While a client-side application is hardly available to another user without some extra-effort, a database stored procedure is a great way to share functionalities. Stored procedures are available on the database server-side, so sharing them is just a matter of providing access to the database.

Enhance CUBRID with new features! Whenever you need a new feature in CUBRID, a great way to start can be through developing a stored procedure. Of course, you could always choose to contribute with your code to the CUBRID engine, but developing a Java stored procedure is much simpler.

And these are not the only reasons to use stored procedures – think about performance and usability; all these are valid reasons to enhance your CUBRID database with Java stored procedures.

“How-To” CUBRID Java Stored Procedures

To create a CUBRID stored procedure, the mandatory steps are:

• Configure the environment – see http://www.cubrid.org/manual/840/en/Environment%20Configuration%20for%20Java%20Stored%20Function|Procedure
• Enable support for stored procedure in the database (please note that by default this is “off”); read more at http://www.cubrid.org/manual/840/en/How%20to%20Write%20Java%20Stored%20Function|Procedure#conf
• Develop and Compile the Java stored procedure source code
• Load the compiled Java class into the CUBRID database, using the loadjava tool
• “Publish” the loaded Java class/Function or Procedure, by defining the SQL interface (the “call specification” – see http://www.cubrid.org/manual/840/en/Call%20Specifications)

We will not go here into more details about these steps, because the online/offline documentation already covers this topic in details – see http://www.cubrid.org/manual/840/en/How%20to%20Write%20Java%20Stored%20Function|Procedure.

In CUBRID, there are two types of database stored procedures:

• Procedures; these are stored procedures which do not return a value
• Functions; these are stored procedures which return a value back to the “caller”

For Functions, the valid data types which can be returned are any of the CUBRID SQL data types (except BLOB/CLOB), or the CURSOR data type (which is used for when the code returns a Java ResultSet):

Beside this difference regarding the return value, there are no other differences that separate procedures and functions. Therefore, unless when explicitly specified, whenever we will refer to “stored procedures” in this document, it means that it applies to both types.

As the scope of developing a stored procedure in a database is generally associated with the need of accessing the data in the database, we will refer in this document only to the second type of stored procedures – which have access to the database.

Connecting to the database

As a general rule, because a stored procedure is nothing else but Java code, all the rules about connecting and accessing a database via JDBC do apply.

In particular, because a stored procedure is already “attached” to a database, to connect to the “current” database, all you need to do to get a database connection in code is:

Of course, you can connect to any other database as well from the stored procedures code, CUBRID or not, there are no limitations – it is nothing else but standard JDBC programming.

Recommendation: The next thing to do, after successfully connected, is to setup the connection encoding:

In the next sections, we will go through some concrete example of developing Java stored procedures.

A simple stored procedure example

Let’s create a stored procedure, which replicates the COUNT() SQL function; it will get as an input parameter the name of the table and it will return the number of records in that table.

Here is the (simplified) Java code:

After compiling the code, we will load the compiled class in the database, using the loadjava utility:

Then, we need to create the call interface, so we can access the procedure from SQL.

If you are using CUBRID Manager, you can take advantage of the built-in UI interface:

Or you can just use plain SQL:

Once created, you can see the stored procedure in CUBRID Manager:

…Last step – use it from SQL!

There are various ways to execute it:

or

Note: There are no verifications for the correct data type for the input parameters!

For example, calling with a numeric argument, will simply output 0, without any error messages:

Remember:

CUBRID stored procedure names are not case sensitive.

The maximum name length is 256

The maximum number of parameters a stored procedure can have is 64.

Another example: Accessing the file system

As we mentioned before, using Java stored procedures gives access to a whole new world of functionalities which are not available from SQL by default - you can use almost all the Java capabilities right from within CUBRID.

In particular, one important benefit that worth mentioning is getting access from the database to the file system.

We will illustrate this with an example of a stored procedure which will output data in a file. In particular, because CUBRID is missing an export-to-xml function or a similar built-in tool, let’s create a stored procedure which will take as an input argument a SQL SELECT statement and will output the result set in an XML format.

We will keep things simple, no XML parsers and a quite simple schema; of course, following this example, you can extend it to create more complex functionality.

Here is a part of the Java code:

After compiling, loading in the database and creating the interface we will be able to use this stored procedure from SQL:

Let’s dump the data from the code table in the file:

And here are the results:

Summary

As you can see, there are so many new things you can accomplish when you combine the power of Java with a CUBRID database! …And there is nothing complicated or hard to do!

So when you need a new functionality in your application, first consider if a store procedure is a good solution approach.

Also, you should know that stored procedures are not a universal solution to any problem - they have their own disadvantages:

Are very hard to debug.

They can “hide” the business logic, making hard to understand how they work/what do they do exactly.

There are limitations when combining SQL and Java, especially when you need to deal with result sets.

Links & Resources

This concludes the first CUBRID Java Stored Procedures tutorial. In the next tutorial about CUBRID Stored Procedures, we will see how to use stored procedures which return a result set. Please let us know your feedback and remember to periodically check the CUBRID web site – www.cubrid.org/tutorials - for more tutorials and resources.

Thank you!