Ruby ORM and other tools for CUBRID Database System


My name is Esen S… I am a developer and a project manager at
CUBRID Database Development Team. First, let me briefly introduce
CUBRID. It is an free open source relational database management
system highly optimized for Web applications (
We have developed the stable Drivers for JDBC and PHP. Recently the
members of our open source community have contributed the code for
Ruby Driver to connect to CUBRID Database, including the ORM based on

In my opinion, Ruby community is the most active and aggressive
programmers’ community with above average professional developers. So,
I am looking for contributors who can help our team test, fix bugs,
and develop the stable drivers and mapping tools that could be open to
entire Ruby Community. We have already a pretty strong code base to
start from at CUBRID SVN in (Best Open Source Mac Software 2023
cubrid), so the contributors will not have to start from scratch.

Any advice and recommendations are strongly encouraged. If you think
you can suggest us how to build a strong structure for Ruby driver, or
where to start from for rapid development, please, do not hesitate to
reply to this post. I will be tuned with the Ruby on Rails: Talk


On Jul 21, 3:07 am, CUBRID [email protected] wrote:

where to start from for rapid development, please, do not hesitate to
reply to this post. I will be tuned with the Ruby on Rails: Talk

One good place to start would be making the ActiveRecord adapter and
the Ruby driver available on Gemcutter. I was eventually able to
locate the adapter via Google, but the page is tricky to spot since
it’s 90+% in Korean…

You’ll probably also want to be more explicit about what makes Cubrid
different from, say, MySQL. I found this:

Which mentions the INCR() function, which sounds a lot like the in-
place operations that MongoDB (and others, I’m sure; I’ve seen it in
Mongo…) provide. However, there isn’t any evidence of any other
operations of this type (besides the obligatory DECR()) so it feels
like a micro-optimization to support a single highly-specific use
case. And am I correctly reading that it doesn’t commit / rollback
with the enclosing transaction? (!)

I’m also curious about a couple design decisions that I noticed
skimming over the docs:

  • the “monetary” type is represented as a double-precision floating-
    point number. AFAIK, that’s almost exactly the opposite of
    conventional best practice for storing money values.

  • there is a “bit” type, but the ActiveRecord adapter doesn’t use it,
    instead adopting the MySQL adapter’s convention of an int(1). This
    struck me as odd, especially since the “converting from MySQL” guide
    explicitly recommends replacing MySQL ‘boolean’ fields with ‘bit’

  • there’s something going on with object-orientation, but the
    homepage is pretty much silent regarding the issue and the wiki isn’t
    much more help. Is this an experimental feature?

Finally, you’ve got the “nobody ever got fired for buying IBM”
problem; unless you can deliver huge wins over the more conventional
options at the same price point (MySQL, Postgres, etc), there’s simply
a lot of inertia (both in terms of language support and the tool
ecosystem) to work against.

–Matt J.

Hello Matt,

That’s a great feedback! Thank you very much for responding to my
request. Below I will answer to each of your doubts and questions.

  1. Thanks for pointing about Gemcutter. I will register an account
    over there and share Ruby Driver and Adapter. Concerning the
    difficulty to find them, in my first message I have pointed to Project URL (Best Open Source Mac Front-Ends 2023),
    which has all binaries for CUBRID Database, including PHP, JDBC, and
    Ruby drivers. Here is the Files Directory
    Best Open Source Mac Front-Ends 2023.
    You will see there “CUBRID Ruby Driver” directory dedicated for Ruby

  2. Related to why CUBRID and what the differences are, here is my
    answer directly to the point. These days we are attending the OSCON
    Open Source Convention Conference in Oregon. We see that Oracle is
    developing MySQL not that aggressively as it was before. Many strong
    former MySQL developers and architects are leaving the company as they
    have some personal doubts. It’s a fact, and the world knows it. Some
    ex-MySQL coworkers join other projects like MariaDB or MongoDB. Do you
    think it’s because MySQL is getting stronger? I personally doubt that.
    From the beginning Oracle has been concentrated on making money, and
    they have enough strong tools to monetize. Regarding MariaDB and
    MongoDB, there are so many issues with them. Here is just one example
    why developers move back to MySQL ( is for sale | HugeDomains
    scatter/were-back-so-long-mongodb/). These solutions are not that
    stable. But CUBRID is behind the largest IT service provider in Korea

  • NHN. It has a strong maintainer and investor. Besides, NHN itself is
    a very big reference. For instance, NHN possesses 76% market share in
    the Korean search market while Google - only 4%. These figures tell a
    lot. And these days NHN switches most of their services to run on
    CUBRID, and they have a farm of over 10,000 servers. It’s a great
    potential. CUBRID serves even one of the largest game industry leaders
    like Mgame (
    default.mgame). This entire game is running on CUBRID Database. When
    investing in some business you don’t think of the current cash flow
    but on the future potential, on the guarantee. And NHN is a big player
    which has a huge interest in CUBRID’s being widely used within the
    company and outside. And community users, developers and business
    owners need a stable product. This is where CUBRID is different from
    others. If CUBRID does not have something that other solutions have.
    It’s just temporarily. This week we have released CUBRID R3.0 Beta,
    which brings huge functional improvements (
    curbid_r30_beta) and SQL syntax extensions. Now it’s more compatible
    with MySQL than ever before. Everything - for the user. Now we started
    the second MySQL Compatibility phase. We expect the Full compatibility
    by the end of this year. Before that CUBRID 3.1 is planned to
    introduce the new FBO feature. File-Based Object will allow users to
    store BLOB/CLOB data into the file system which is outside of
    database. Mostly this feature is implemented on the application level,
    however if it is implemented on the database level, the applications
    will not need anymore to access the file system separately. Instead
    only SQL data types (LOB data) in SQL queries can be used. The
    distributed file system for this feature will be POSIX, which is open
    source. Another important improvement for the next CUBRID R3.2 will be
    the Clustering capability for CUBRID database, which will provide the
    linear scalability without modification of applications, as well as
    distributed partition and load balancing features. CUBRID Cluster will
    support the single database view while providing the multi access
    point to databases. This feature will be very interesting for large
    enterprises. These are only the changes CUBRID users we’ll see in this
    half of the year. This is to prove that CURBID is not just another
    database, we invest a lot to make it the most compatible, ease-to-use
    and highly optimized database for Web applications.
  1. Matt, in order to dramatically increase INCR/DECR performance
    CURBID passes by COMMIT/ROLLBACK. So, these two functions do not leave
    the tracks behind. Once they are embedded in the query, the results
    are immediately committed.

  2. Concerning the “MONETARY” data type, yes, it is represented by the
    DOUBLE PRECISION floating point.
    DOUBLE PRECISION has higher precision than that of FLOAT or REAL. So,
    that’s why it’s more rational to use DOUBLE PRECISION. However, most
    DB users usually, not only with CUBRID but with MySQL and MS SQL as
    well, do not use the MONETARY (or MONEY) data types to store the
    monetary values. They often refer to the NUMERIC data type, if they
    will. But with MONETARY in CUBRID the number of significant digits is

  3. So, there should be anything to be afraid of. In case, this is not
    enough, there is always a way out with the NUMERIC.

  4. In MySQL most types are stored in the binary format. Before 5.0.3
    they were stored as strings. Moreover MySQL itself has a BIT data
    type. By default BOOL/BOOLEAN defaults to TINYINT(1). But this is not
    strict enough. If you really want the BOOLEAN type, you should use
    type BIT(1), which will allow you to use exactly 1 and 0 and may save
    space for you. This is what exactly CUBRID BIT does.

  5. Concerning the Object-side of CUBRID, here is a detailed answer I posted on CUBRID
    Forum. Briefly speaking, it’s not an experimental feature. Vice versa,
    it’s something that was fully developed before. The object orentation
    feature was requested by Game Developers. As a result here is where
    Object part of CUBRID is massively used
    However, these days the web developers request the features which are
    on the ‘relational’ side.

Matt, if you have any other questions, let me know. I will be very
glad to answer you. I hope to hear your feedback on Ruby Driver and

Hello Matt,

I have pushed CUBRID gem to the, so now you can install
Ruby driver for CUBRID using “gem install cubrid” command. Right now I
have tested with Ruby 1.8.7, later today I will test for 1.9.1 and
push the gem. If you have any questions, I will be glad to know your