Can someone explain this to me

Rails
1

Hi

I was reading some articles and I came across this one in how to manage
the database.yml file when you have multiple developers. (To prevent
passwords and such being in SVN etc…)

login: &login
  username: defaultuser
  password: defaultpassword

<%= file = File.join(RAILS_ROOT, "config", "dblogin.yml")
    IO.read(file) if File.exist?(file) %>

development:
  adapter: mysql
  host: localhost
  database: foo_development
  <<: *login

Firstly where I’m confused is the &login block (near login:) How is this
ever processes or passed info and subsequently where is it referenced?

Secondly the <<: notation. (I can’t find anything explaining this in the
pickaxe book or online), but I bet I"m just missing it. What’s it
purpose?

The “ERB” part where it reads a file if it exists and adds the info in
this file TO the database.yml is pretty clear but why the login block
and the <<: ?

Thanks.

2

cd config
svn propset svn:ignore database.yml .

This will ignore the database.yml file providing you haven’t yet
committed
it. If you have committed it, delete it and then do that line.

On Thu, Feb 21, 2008 at 1:53 PM, Jean N. <
[email protected]> wrote:

password: defaultpassword

Thanks.

Posted via http://www.ruby-forum.com/.

–
Ryan B.

Feel free to add me to MSN and/or GTalk as this email.

3

IO.read(file) if File.exist?(file) %>

Secondly the <<: notation. (I can’t find anything explaining this in the
pickaxe book or online), but I bet I"m just missing it. What’s it
purpose?

The “<<:” line along with the “login: &login” line is saying that the
entries under the login: block (cause it’s associated with &login, not
cause the first part is login) should be included in the development
section.

Basically it let’s you share common entries across all your entries
without having to specify them over and over again.

But like Ryan said, don’t track database.yml in SVN. Ignore it. Create
a
database.yml-production that gets moved into place for production and
let
each developer create their own database.yml for their environment.

4

On 21 Feb 2008, at 05:49, Jean N. wrote:

the username: password: From the read file and not all the other
stuff.

Because yaml uses indentation to track how far a chunk goes (or in
other words, the same way yaml knows that

foo:
id: 1
bar:
id: 2

in one of your fixtures files represents 2 rows in the database, not one

Fred

5

The “<<:” line along with the “login: &login” line is saying that the
entries under the login: block (cause it’s associated with &login, not
cause the first part is login) should be included in the development
section.

Basically it let’s you share common entries across all your entries
without having to specify them over and over again.

But like Ryan said, don’t track database.yml in SVN. Ignore it. Create
a
database.yml-production that gets moved into place for production and
let
each developer create their own database.yml for their environment.

(Thanks to you and Ryan both on your help)

Maybe I should ask if there is a reference somewhere I can read up on
this…

but I’m still confused how the block is begun/ended. It’s easy enough to
see with do/end or curly braces…but this notation is just foreign to
me. (Summarized question, how does the <<: *login know to insert only
the username: password: From the read file and not all the other stuff.

Sorry I realise I’m moving off Rails into more Ruby questions now…

Your help is very appreciated.

6

On Feb 21, 2008, at 12:49 AM, Jean N. wrote:

Create
but I’m still confused how the block is begun/ended. It’s easy
enough to
see with do/end or curly braces…but this notation is just foreign to
me. (Summarized question, how does the <<: *login know to insert only
the username: password: From the read file and not all the other
stuff.

Sorry I realise I’m moving off Rails into more Ruby questions now…

Your help is very appreciated.

The issue is that &login is not a “block”, this is YAML not Ruby. You
read up on it go to the spec linked from YAML Ain’t Markup Language (YAML™) Version 1.1
the YAML home page.

As for whether to keep database.yml in the repository, I vote yes –
even if you put a different file in place on production during
deployment. Here’s how I’ve done it:

vvv Copy the following two YAML maps to a file called config/

mydatabase.yml

login: &login
username: default_user
password: default_password

connection: &connection
host: 127.0.0.1
port: 3306
encoding: utf8

^^^ Copy the previous two YAML maps to a file called config/

mydatabase.yml

<%= file = File.join(RAILS_ROOT, “config”, “mydatabase.yml”)
IO.read(file) if File.exist?(file) %>

development:
adapter: mysql
database: projectname_development
<<: *login
<<: *connection

Those lines are taken directly from a database.yml (changing only
username, password, and database to protect the guilty). This file is
in the repository. I split the login credentials from the connection
parameters to deal with the port versus Unix socket of MySQL and on a
recent project, even split out the adapter so cope with PostgreSQL
versus MySQL.

The mydatabase.yml file contains just those YAML maps that need to be
changed from the default. Typically I only have the connection
specified. The mydatabase.yml file is never in the repository. I
keep mydatabase-production.yml locally as a backup to the one in
production. I’ve also seen a similar arrangement that reads the
separate YAML file a second time at the end of the database.yml, but I
don’t recall the reason that was done (although I remember that the
explanation made sense for what was being done).

-Rob

Rob B. http://agileconsultingllc.com
[email protected]

7

Jean N. wrote:

Then if I put (anywhere in the yaml file) <<: &a_block it will inline
everything I have defined as that block?

This should have read “<<: *a_block it will inline…”

Sorry.

8

Frederick C. wrote:

On 21 Feb 2008, at 05:49, Jean N. wrote:

the username: password: From the read file and not all the other
stuff.

Because yaml uses indentation to track how far a chunk goes (or in
other words, the same way yaml knows that

foo:
id: 1
bar:
id: 2

in one of your fixtures files represents 2 rows in the database, not one

Fred

Okay so

Login: &a_block
username: foo
password: bar

KNOWS That I am ‘naming’ the Login section “a_block”.

Then if I put (anywhere in the yaml file) <<: &a_block it will inline
everything I have defined as that block?

Very neat…

Am I correct in assuming <<: Is a yaml operator? (As I can’t find it in
any of my references)

Thanks everyone.