Ruby on Rails

We have toyed with creating separate databases for each customer as our
combined one is starting to get quite large. In our case, the models will
always be the same no matter which database you are connecting to, so
there isn't any meta-programming involved. It's just a case of switching
databases to the correct one for that customer once they log into the
system.

One thing to consider is that shared data needs to go somewhere (sessions,
username/passwords etc) as well.

Cheers
Simon





On Thu, 04 Apr 2013 16:34:21 +0800, Julian Leviston
<julian@coretech.net.au> wrote:

> Okay...
>
> So to do this, you need to understand meta-programming to a degree
> because that's what you're doing.
>
> In normal Rails, you'd create a model as part of the development
> process, but what you're doing is creating some code that creates models
> itself (ie one level of abstraction higher than normal).
>
> The equivalent straight ruby comparison is: (compare 1, with 2, below):
>
> 1. Creating a class (this is normal programming)
>
> class Cat
> def hi
> puts 'meow'
> end
> end
>
> You can then create new Cat objects like this:
> furrycat = Cat.new
>
> and make it meow like this:
> furrycat.hi
>
> 2. Creating a piece of code that creates a class (this is
> meta-programming)
>
> a_class = Class.new
> hi_method_block = Proc.new{ puts 'meow' }
> a_class.send(:define_method, :hi, &hi_method_block)
>
> You can then create new "Cat" objects like this:
> furrycat = a_class.new
>
> and make it meow like this:
> furrycat.hi
>
> ---
>
> So... assuming you followed that, then you'll understand that you could
> do the same thing with ActiveRecord::Base classes, which is what forms
> the bases for Active Record model classes. This is how you'd dynamically
> LOAD one of your programmatically generated models. Creating the table
> is just a matter of executing some arbitrary SQL which can be built
> using ActiveRecord::Base.connection.execute. (Eg to run a count of a
> fictitious users table, you'd do this:
> ActiveRecord::Base.connection.execute("SELECT COUNT(*) FROM users;")
>
> However, like I said, there's no point trying to do this until you can
> walk, because this really is running. Most Rails devs hardly ever get
> into this stuff. I've been a Rails developer since 2005, and I've only
> done this sort of dynamic table and database thing once or twice in
> practice.
>
> Julian
>
> On 04/04/2013, at 6:43 PM, Johan Vauhkonen <johan.vauhkonen@gmail.com>
> wrote:
>
>> Thanks for posting, I appreciate the feedback.
>>
>> I'll start with keeping everything within a single database and take it
>> from there.
>>
>> You are right Julian in that I am new with RoR and what I've asked for
>> is advanced.
>>
>> I'm still curious though how creating databases dynamically would be
>> done so if it's explained anywhere I'd love to read it!
>>
>>
>> 2013/4/4 Julian Leviston <julian@coretech.net.au>
>>
>> On 04/04/2013, at 6:05 PM, Johan Vauhkonen <johan.vauhkonen@gmail.com>
>> wrote:
>>
>> > Thanks for replying, Julian.
>> >
>> > Can you point me to any resources that describe how to do it?
>> >
>> > I agree that I should not optimize prematurely but what I'm
>> considering is which is easier,
>> > to go with dynamically creating databases from the start or to
>> extract data from the single database to new databases later on?
>> >
>> > It's at least something to keep in the back of my mind.
>>
>> Hi,
>>
>> You shouldn't attempt to do this if you don't already understand enough
>> Ruby / Rails to do it yourself.
>>
>> So, I suggest sticking with what you *can* do first.
>>
>> This might sound like a cop out, but there's very good reason. It's
>> very advanced Rails and you really shouldn't attempt something like
>> this until you understand the basics really well IMHO.
>>
>> Julian
>>
>> --
>> You received this message because you are subscribed to a topic in the
>> Google Groups "Ruby on Rails: Talk" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/rubyonrails-talk/S73DxPeqvy4/unsubscribe?hl=en-US.
>> To unsubscribe from this group and all its topics, send an email to
>> rubyonrails-talk+unsubscribe@googlegroups.com.
>> To post to this group, send email to rubyonrails-talk@googlegroups.com.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>>
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Ruby on Rails: Talk" group.
>> To unsubscribe from this group and stop receiving emails from it, send
>> an email to rubyonrails-talk+unsubscribe@googlegroups.com.
>> To post to this group, send email to rubyonrails-talk@googlegroups.com.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>

--
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-talk+unsubscribe@googlegroups.com.
To post to this group, send email to rubyonrails-talk@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.