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 <[email protected]>: > 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 > <[email protected]> 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 <[email protected]> >> 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 <[email protected]> >>> >>> On 04/04/2013, at 6:05 PM, Johan Vauhkonen <[email protected]> >>> 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 >>> [email protected]. >>> To post to this group, send email to [email protected]. >>> 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 [email protected]. >>> To post to this group, send email to [email protected]. >>> 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 > [email protected]. > To post to this group, send email to [email protected]. > 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 [email protected]. To post to this group, send email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
