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...)
<%= file = File.join(RAILS_ROOT, "config", "dblogin.yml")
IO.read(file) if File.exist?(file) %>
development:
adapter: mysql
host: localhost
database: foo_development
<<: *login
[/code]
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 <<: ?
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...)
<%= file = File.join(RAILS_ROOT, "config", "dblogin.yml")
IO.read(file) if File.exist?(file) %>
development:
adapter: mysql
host: localhost
database: foo_development
<<: *login
[/code]
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 "<<:" 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.
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...
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.
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
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
# ^^^ 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).
