Ruby on Rails

That kind of scenario was what I had initially in mind. Everyone has
the same models, just not the same database.

2013/4/4, Simon Macneall <macneall@gmail.com>:
> 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 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.