I Thought Rails Was Meant To Be Productive…
Why is it that a hugely database dependent framework, that's meant to be extremely quick to get up and running with is so infuriating when it comes to get it actually talking to the database? I know cross-language interfaces are always difficult, particularly when you try to make them work cross platform but if I can get Java, PHP and perl all talking to MySQL easily, why does it have to be so damn hard for ruby?
Perhaps more importantly, why the heck do I need to? Developer time is meant to be sacred, so why isn't there a pure ruby embedded database that comes with rails? Why do I have to fight with the MySQL bindings before I can start developing, why do I have to configure where my database is and provide three separate configurations for testing, development and production? Why can't Rails just do it for me? Sure I probably don't want to develop my entire application on an embedded database and then hope it all works when I go live on something that can scale better, but at the same time, do I really need to go through configuration hell before I can do anything with Rails?
I think I'm really starting to appreciate the value of Apache Derby.
September 2nd, 2006 at 3:53 pm
The Rails guys probably didn’t want to write a pure-Ruby embedded database because there’s a reasonable altrenative already — SQLite (http://www.sqlite.org/). Bindings available as gems or in your (or at least my) favourite distro’s package repositories. Trivial to setup. As long as you stick to migrations and ActiveRecord for all your database interfacing, it’s perfectly fine to use — it’s “dialect” of SQL is a bit more limited than MySQL’s, so if you’re executing queries directly against the DB it’s unlikely to be too healthy.
As for having to setup separate dev/test/prod databases, I think the separation of concerns in Rails’ environments concept is an amazingly powerful one, and if Rails’ only lasting legacy was the universal adoption of such a concept, I’d almost be satisfied. If you really want minimal-time config, though, you can just define one environment and then tell the others to “inherit” from that, like so:
development:
adapter: sqlite3
dbfile: db/devel
test: development
production: development
September 3rd, 2006 at 8:12 am
Matt,
SQLite has the same problems as MySQL - you have to get past all the Ruby to C interface stuff. Setting up the MySQL server itself is trivial, getting Rails to talk to it is exceptionally frustrating - just look at all the blog posts and wiki pages asking for help with it. A pure Ruby database would avoid this because it wouldn’t have a native component that has to be tailored for each system. Having a default embedded database also has the advantage of eliminating the need for configuration before you start developing.
Also, the distinction between databases is good, the fact that I have to configure three different databases is bad. With an embedded database Rails would just create the three separate databases for me with no configuration required. You’d still have the ability to configure it to use MySQL if you knew your app required that, but by default it would just work.
September 3rd, 2006 at 8:17 am
Adrian, Rails actually ships with a Ruby-based MySQL adapter. You don’t need the C-based one, except for speed. Also, you don’t have to configure three databases. You can start out just configuring the development one. Then once you need the other environments, you can configure those.
With SQLite, the creation of the three databases is all handled automatically, though. Just create a new rails app with “rails –db sqlite2 myapp” and its even configured for you as well.
September 3rd, 2006 at 9:14 am
DHH,
Then why doesn’t it work consistently, reliably, everywhere, first time? Maybe it’s something simple but the error messages are completely useless. Either way I’ve wasted far too much time on this - if I can’t get it working I can’t expect anyone else to so for now Rails isn’t a good solution for this project. I need something that I can give to clients and know that they’ll be able to get it up and running on their system in a couple of clicks. Rails I’m sure will get to the point where it can do that, but it’s not there yet.
Great to hear that rails automatically configures SQLite though. It still has the downside of needing to get the integration with SQLite working - if that’s seemless then great, but I don’t hold very high hopes considering my past experiences with anything and SQLite and Rails and MySQL.
September 4th, 2006 at 4:40 am
Adrian, which environment do you work in where database connectors doesn’t need to be installed and they don’t need to be configured? In any case, please do get specific and we can help you solve the problem. What’s the error message you’re seeing and what’s the setup you’re running on?
Rails automatically configures for SQLite, and any other database we support, by using the –db option when you create a new application. We can’t, however, guess your user name and password. Although we actually try (by default its root/nothing for MySQL, which is what its out of the box for that database).
September 4th, 2006 at 4:43 am
BTW, to install the C-bindings for MySQL, you do “gem install mysql”. To install the C-bindings for SQLite, you do “gem install sqlite-ruby”. I’d file that under “easier than most”.
September 4th, 2006 at 6:40 am
It’s not the configuration side that is the centre of my complaint - having to configure a MySQL username and password is unavoidable when using MySQL and Rails does make that easy. The centre of the complaint is that getting the integration to work with MySQL in the first place is too difficult. On OS X I had to go searching for what parameters to pass in to specify the MySQL header files location and then had to tell rails where the ruby header files were (something I’d not seen before). On Windows the install was fine, but rake migrate gave an error about missing the “each” method. After uninstalling everything and attempting a different path I got an error about a missing DLL, and so on.
Each of these problems is almost certainly something particularly unusual about my setup and on OS X I’ve gotten it working now. My problem is that I want to be able to send the application out to end clients so they can run it on their systems. I really need it to be as simple as double-clicking a file to get it started and right now unfortunately Rails doesn’t seem up to that.
In terms of which system I can do that with - Java. There are actually a lot of apps being distributed this way very successfully today. With Apache Derby there is no problem with database logins or connectivity issues and bundling in a Tomcat server is simple to do. Plus a huge number of sysadmins already have experience deploying Java applications, whereas few have experience with rails deployment so far.
That’s not to say that Rails doesn’t show a lot of promise, doesn’t have huge benefits when you are running it from your own servers or that Rails won’t be double-click deployable in the future, it’s just not quite there yet.
September 5th, 2006 at 1:58 pm
It obviously depends on how you bundle it. Before I even released Rails, I released a no-step-three wiki called Instiki. You can still download it. I think its available both as an .exe and as an .app file. It shipped everything in the box. 0 dependencies. Ruby didn’t even have to be installed (it came with the bundle).
In any case, you must of course use what you feel comfortable with.
September 17th, 2006 at 2:40 am
Hi,
Just wanted to give you an heads-up that you now can use Apache Derby (or HSQLDB) in Rails, if you run under JRuby.