The title already says it all. But I will tell in more detail about the early development and interaction of CUBRID with CodeIgniter. Also here you will learn about the differences between CUBRID and MySQL in terms of developing and adapting applications.
At the beginning of this month I
decided to work on the CUBRID driver for CI, a popular PHP framework that is used by so many Web developers. One of the web services in our company wants to use CI with CUBRID. Fortunately, this framework has a rather intuitive structure that allowed me to quickly find the classes that need to be inherited and implemented for CUBRID.
I found all other supported DBMS drivers in the
/ system / database / drivers directory. Since CUBRID supports over 90% of the MySQL SQL syntax, there was no need to start everything from scratch. I started working on a ready-made MySQL CI driver. The next day I already had the working code CUBRID driver. A couple of days later, I conducted tests (unfortunately, as one of the CodeIgniter developers said, they do not yet have unit tests that would cover the entire framework, including the database drivers, so I had to write my tests). As soon as the driver passed all the tests, I contacted their developers and sent
pull requests to the main branch and the development branch.
')
Below I will describe what parts of the code I changed in the MySQL driver to work consistently for CUBRID. I hope these entries will be useful to those who are planning to include support for the CUBRID DBMS in their Web applications.
- Base name at the time of connection
Unlike MySQL, the connection in CUBRID is made directly to the database, i.e. DSN should contain information about the database to which you are going to connect. This method eliminates the need to "choose a base" after the connection. In principle, Oracle also works.
$conn = cubrid_connect($this->hostname, $this->port, $this->database, $this->username, $this->password);
- Port Broker
By default, 33000 is a Broker port. If necessary, this value can be changed in the Broker parameters .
- Auto commit
By default, auto_commit is disabled in the CUBRID DBMS (OFF). This means that developers need to commit each transaction. Thus, users can process requests in the so-called dry mode , when they can receive the results of the queries without changes to the database. Useful during development. By bringing the site into real mode, you can change the value of auto_commit to ON in the CI database.php configuration file, as indicated below, or directly in the Broker settings.
$db['default']['hostname'] = 'localhost';
$db['default']['port'] = '33000';
$db['default']['username'] = 'dba';
$db['default']['password'] = 'ci_pass';
$db['default']['database'] = 'ci_demo';
$db['default']['auto_commit'] = TRUE;
$db['default']['dbdriver'] = 'cubrid';
$db['default']['dbprefix'] = 'tbl_';
- Quoting column names
Sometimes you need to create a column with a name that is already reserved by the DBMS itself as a keyword. In MySQL, for example, such identifiers (table / column / view names, etc.) can be placed in left quotes, for example, `time`. In MSSQL, you must use square brackets ([time]). In Oracle, double quotes ("time").
In CUBRID, you can use all three: left and double quotes, and square brackets. You can use double quotes to highlight identifiers by default, since the value of the ansi_quotes parameter in the cubrid.conf CUBRID configuration file is set to no (that is, do not use double quotes to highlight string values). If this value is changed to yes , then double quotes can be used only for string values. Thus, you can use the character you are used to as a frame for identifiers.
| Quoting identifiers | String edging |
ansi_quotes = NO (default) | left quotes`time` square brackets [time] double quotes "time" | single quotes for string values: 'normal string' |
ansi_quotes = YES | left quotes`time` square brackets [time] | single and double quotes for string values: 'normal string', "normal string" |
- Optimization, Fix, Backup
CUBRID does not provide the ability to manipulate these functions through SQL queries. If you need to optimize, fix the database or make backups, you must use the main administration tool CUBRID Manager .
In addition to these differences, I did not make any other changes in SQL queries, since almost all MySQL queries work in CUBRID. This shows how CUBRID is compatible with MySQL and how easy it is to make a port of applications working with MySQL.
With this example, I wanted to show that adapting applications, even as large as CodeIgniter, is very easy, and it will take no more than a few days for a newcomer to CUBRID. Therefore, if you intend to adapt something, do not hesitate. It does not take much time, you will see for yourself. And yes, if you need help with this, let us know in
our forum and we will be happy to assist you.
As for the source code of the CUBRID driver, as you already think, I know, CodeIgniter recently officially
transferred to the GitHub service. A few days before that, I had already committed changes to their upcoming
repository , which is now closed, and its code was merged with the official one.
Immediately after switching to GitHub, one of their developers reported that CI will roll out support for CUBRID already in version 2.1.0. Will wait!
And if you do not want to wait and already wish to test CI + CUBRID, you can merge the code from the branch to
develop their official repo. If you are lucky enough to find a bug, I will be happy to fix it immediately. You can report it on our forum or on
Twitter .
If you have questions about installing and working with CUBRID, write in the comments. Also, if there are ideas about an application for which you can develop a CUBRID driver, write. I would be glad to talk about them.