Database Config as DSL

Rails
#1

In listening to this week’s Ruby on Rails Podcast the issue of YAML came
up, and it got me thinking. Yes, YAML is very simple and cleanly defines
both the database configuration and fixtures, but couldn’t the same
thing be accomplished in Ruby? Jamis and others have encouraged the use
of DSLs to simplify and clarify code. Since Django (whose author was on
the podcast) uses Python to describe its database configuration, why not
use Ruby for Rails’?

Here’s a sample of a DB config in the DSL:

common {
adapter “mysql”
username “root”
password “”
host “example.com”
port “3306”
}

development {
<< “common”
database “app_development”
}

production {
<< “common”
database “app_production”
}

test {
<< “common”
database “app_test”
}

I did get this working as an instance_eval style DSL, except that the <<
lines had to have “self” preceding them; Ruby expects the << operator to
be operating on something (Does anyone know a way around this?).
Basically it produces a Hash-of-Hashes as the result.

I could forsee that this would be a great way to describe fixtures as
well, since it’s already Hash data, it could just be passed to
ActiveRecord and “BAM!” you have a fixture object.

Your thoughts?

Sean C.

#2

Sean C. wrote:

In listening to this week’s Ruby on Rails Podcast the issue of YAML came
up, and it got me thinking. Yes, YAML is very simple and cleanly defines
both the database configuration and fixtures, but couldn’t the same
thing be accomplished in Ruby? Jamis and others have encouraged the use
of DSLs to simplify and clarify code. Since Django (whose author was on
the podcast) uses Python to describe its database configuration, why not
use Ruby for Rails’?

Here’s a sample of a DB config in the DSL:

…

Sean C.

Hi Sean,
Although we could do this, I would like to know, why?
YAML is easier, no need for curly braces or quotes
YAML is mch more extensible, although you probably won’t ever need
someone parse your db config, for fixtures, you can put them in YAML so
other programs can use that data.
Lastly, YAML is already there, it is how it is done now, and there is no
reason to change it, and send all current tutorials out of date and
confuse people new to the langauage.

Why do you think we should change it to a DSL?

Chris

#3

Hi Sean,
Although we could do this, I would like to know, why?

At least as an academic exercise – but also with a DSL you also have
the full power of Ruby without needing to rely on ERb.

YAML is easier, no need for curly braces or quotes

Yes, but it also has specific requirements about spacing.

YAML is mch more extensible, although you probably won’t ever need
someone parse your db config, for fixtures, you can put them in YAML so
other programs can use that data.

How is YAML more extensible? I find Ruby MUCH more extensible. However,
you do have a point about allowing other programs to use the data.

Lastly, YAML is already there, it is how it is done now, and there is no
reason to change it, and send all current tutorials out of date and
confuse people new to the langauage.

Although I’m not saying it’s better, some things in the framework have
been phased out because something better came along. There’s no reason,
especially with Rails, to do something simply because “that’s the way we
have always done it.”

Why do you think we should change it to a DSL?

Tighter integration I guess is my idea. Of course, I don’t see why both
couldn’t be supported.

I had posted about this on my blog too and my wife, who is not a
technical person, read the code and was able to understand it – and
that’s part of the goal of DSLs, readability, right? I think that she
could probably read YAML too.

One side-effect of implementing this DSL is that one could use it for
any type of configuration/properties file that could be represented as a
Hash-of-Hashes. When I created the DSL, I put the basic functionality
in a parent class, then added the “<<” operator in a subclass.

Thanks for you thoughts and criticisms.

Sean C.