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).
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 (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
Group.
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:
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
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.
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.
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 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
releases.
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
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/
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/
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.
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.
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
So, there should be anything to be afraid of. In case, this is not
enough, there is always a way out with the NUMERIC.
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.
Concerning the Object-side of CUBRID, here is a detailed answer 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.
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.
I have pushed CUBRID gem to the 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.
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.