Comments on: DB Charmer – ActiveRecord Connection Magic Plugin

By: Alex Gusev

Alex Gusev — Fri, 19 Mar 2010 20:44:00 +0000

I am not about to argue about software ( but i am quite close to that ).

I just asking, how my app will work in this typical situations if i use your plugin. Setting up test app and three db servers for testing is not superfast.

So, thats why i am asking – you know answers already

By: Scoundrel

Scoundrel — Fri, 19 Mar 2010 20:16:00 +0000

What environment did you run it in?
We have such a code in our project:

1
2
3
4
5

module DbCharmer
@@migration_connections_should_exist = Rails.env.production?
mattr_accessor :migration_connections_should_exist
...
end

It means that in all environments but production, the code wouldn’t require your :scraper_db configuration to exist and would silently fall back to default configuration. If you want to change this, create an initializer with the following code:

1	DbCharmer.migration_connections_should_exist = true

By: Stephen

Stephen — Fri, 19 Mar 2010 19:57:00 +0000

ok. now i’m just confused.

By: Stephen

Stephen — Fri, 19 Mar 2010 19:56:00 +0000

ugh. this wasn’t correct. Not sure where the db_magic was lost

class CreateCompetitionDeals :scraper_db

def self.up
create_table(:deals) do |t|
t.string :page_url, :company_name, :company_address, :company_url, :tipping_point, :total_purchased,
:savings, :discount, :deal_price, :caption, :market, :fine_print, :highlights, :type
t.boolean :strange
end
end

def self.down
drop_table :deals
end
end

By: Stephen

Stephen — Fri, 19 Mar 2010 19:55:00 +0000

sorry for formatting

class CreateCompetitionDeals :scraper_db

def self.up
create_table(:deals) do |t|
t.string :page_url, :company_name, :company_address, :company_url, :total_purchased,
:savings, :discount, :deal_price, :caption, :market, :fine_print, :highlights, :type
t.boolean :strange
end
end

def self.down
drop_table :deals
end
end

–

after running this, the main database had a deals table with correct schema. The scraper_db was empty. Rails 2.3.4

By: Scoundrel

Scoundrel — Fri, 19 Mar 2010 19:50:00 +0000

Could you show the migration code here? We use the plugin’s code (migrations part) in scribd for more than 6 months with at least one migration a day – no problems so far.

P.S. And btw, schema_migrations table is created and maintained in the main db only.

By: Stephen

Stephen — Fri, 19 Mar 2010 19:38:00 +0000

Migrations don’t run as expected. Specified a global connection change for the migration and it ran in both the standard & non-default DB. The table in the standard DB was correct. The table’s schema in the non-default was empty.

By: Scoundrel

Scoundrel — Fri, 19 Mar 2010 13:00:00 +0000

I’m a mysql dba and I’m convinced that these kinds of problems should not be solved in the application layer. But if someone would implement something like a slaves pool with automatic dead slaves rejection, I’d accept the patch as soon as it is tested in production somewhere.

By: Alex Gusev

Alex Gusev — Fri, 19 Mar 2010 10:44:00 +0000

It is completely amazing! Such sweet plugin that tested at scribd production… Brilliant!

But, i have three questions:

What will happen when i have:
1) 1 master db and 1 slave db for model and slave going down?
2) 1 master db and 1 slave db for model and master going down?
3) 1 master db and 2 slaves db for model and 1 slave going down?

By: Scoundrel

Scoundrel — Fri, 19 Mar 2010 00:35:00 +0000

1) YourModel.on_master.find(…) – will make the query run on the master

2) Transactions – supported and all the queries will go to the master as well (forgot to mention it in the docs though).