DRYing up shards.yml? #92

Open
zdzolton opened this Issue Apr 20, 2012 · 4 comments

Projects

None yet

4 participants

@zdzolton

Hello,

I'm sure you've thought all this through already, but I have a couple issues with the shards.yml config file.

First off, why do we have to nest everything under the top-level "octopus" key? Is this just namespacing? If so, does any other popular gem actually use a shards.yml file?

Second, it feels un-DRY to have to specify the names of each environment and then to have to repeat those names. I'm sure there's a great argument for the way it's currently specified, and I'd love to hear it!

Thanks,

Zach

@sobrinho
Collaborator
sobrinho commented Nov 2, 2012

I agree with you about the environments section.

For example, I'm using this shards.yml right now:

octopus:
  environments:
    - development

  development:
    shards:
      argentina:
        adapter: mysql2
        database: argentina
        username: root
        host: localhost

      brazil:
        adapter: sqlite3
        database: db/brazil.sqlite3

      canada:
        adapter: sqlite3
        database: db/canada.sqlite3

The environments section can be removed:

octopus:
  development:
    shards:
      argentina:
        adapter: mysql2
        database: argentina
        username: root
        host: localhost

      brazil:
        adapter: sqlite3
        database: db/brazil.sqlite3

      canada:
        adapter: sqlite3
        database: db/canada.sqlite3

The octopus and shards keys aren't necessary too.

So, the shards.yml can be cleaned to:

development:
  argentina:
    adapter: mysql2
    database: argentina
    username: root
    host: localhost

  brazil:
    adapter: sqlite3
    database: db/brazil.sqlite3

  canada:
    adapter: sqlite3
    database: db/canada.sqlite3

It will be more closer to database.yml structure.

What do you think, @zdzolton?

@sobrinho sobrinho was assigned Nov 2, 2012
@eprothro
Contributor

+1

@lawrencepit

Why have a shards.yml at all? Why not use database.yml where common sections can be re-used?

@eprothro
Contributor

The Heroku use case is one good reason, where database.yml is override the
PaaS provider.

Granted, dynamic configuration could be used in that case, but that's true
in all cases I suppose, so the use case still seems valid to bring up in
this context.

-Evan Prothro
Sent from my mobile

On Apr 22, 2013, at 7:10 PM, Lawrence Pit notifications@github.com wrote:

Why have a shards.yml at all? Why not use database.yml where common
sections can be re-used?


Reply to this email directly or view it on
GitHubhttps://github.com/tchandy/octopus/issues/92#issuecomment-16831951
.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment