# Ruby ORM and other tools for CUBRID Database System **URL:** \ **Category:** Rails\ **Created:** [July 21, 2010, 9:29am UTC](https://www.ruby-forum.com/t/ruby-orm-and-other-tools-for-cubrid-database-system/191952 "2010-07-21T09:29:57Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![CUBRID](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/ccd318/32.png) [@CUBRID](https://www.ruby-forum.com/u/CUBRID)\ **Post date:** [July 21, 2010, 9:29am UTC](https://www.ruby-forum.com/t/ruby-orm-and-other-tools-for-cubrid-database-system/191952/1 "2010-07-21T09:29:57Z")
Hello, 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 ([http://www.cubrid.org](http://www.cubrid.org)). 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 ActiveRecord. 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 [sourceforge.net](http://sourceforge.net) ([Best Open Source Mac Software 2023](http://sourceforge.net/projects/) 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 Group. Regards, Esen. ---
**Author:** ![CUBRID](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/ccd318/32.png) [@CUBRID](https://www.ruby-forum.com/u/CUBRID)\ **Post date:** [July 22, 2010, 12:37am UTC](https://www.ruby-forum.com/t/ruby-orm-and-other-tools-for-cubrid-database-system/191952/2 "2010-07-22T00:37:27Z")
On Jul 21, 3:07 am, CUBRID [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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 > Group. 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: [http://blog.cubrid.org/cubrid-life/cubrid-vs-mysql/](http://blog.cubrid.org/cubrid-life/cubrid-vs-mysql/) 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? (!) [http://wiki.cubrid.org/index.php/INCR\_and\_DECR\_Functions](http://wiki.cubrid.org/index.php/INCR_and_DECR_Functions) 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’ fields. - 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. ---
**Author:** ![CUBRID](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/ccd318/32.png) [@CUBRID](https://www.ruby-forum.com/u/CUBRID)\ **Post date:** [July 22, 2010, 11:09am UTC](https://www.ruby-forum.com/t/ruby-orm-and-other-tools-for-cubrid-database-system/191952/3 "2010-07-22T11:09:06Z")
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 [Sourceforge.net](http://Sourceforge.net) Project URL ([Best Open Source Mac Front-Ends 2023](http://sourceforge.net/projects/cubrid)), 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](https://sourceforge.net/projects/cubrid/files/). You will see there “CUBRID Ruby Driver” directory dedicated for Ruby releases. 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 ([Blue74.com is for sale | HugeDomains](http://www.blue74.com/2010/06/) 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 ([http://aw.mgame.com/event/2010/0715\_grandopen/](http://aw.mgame.com/event/2010/0715_grandopen/) 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 ([http://cubrid.org/](http://cubrid.org/) 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 [http://forum.cubrid.org/viewtopic.php?f=12&t=38](http://forum.cubrid.org/viewtopic.php?f=12&t=38) 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 [http://aw.mgame.com/event/2010/0715\_grandopen/default.mgame](http://aw.mgame.com/event/2010/0715_grandopen/default.mgame). 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 Adapter. ---
**Author:** ![CUBRID](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/ccd318/32.png) [@CUBRID](https://www.ruby-forum.com/u/CUBRID)\ **Post date:** [July 30, 2010, 7:14am UTC](https://www.ruby-forum.com/t/ruby-orm-and-other-tools-for-cubrid-database-system/191952/4 "2010-07-30T07:14:42Z")
Hello Matt, I have pushed CUBRID gem to the [Rubygems.org](http://Rubygems.org), 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 opinion. Esen.