Thanks. What I was trying to do is not possible with Heroku at the moment: Sub-sub domains aren't possible on Heroku default domain (yourappname.herokuapp.com), and you need to use the custom record for that
I have multitenancy setup as per this railscast and have just started to learn Minitest Spec. Would you mind sharing some of your testing code to show how you implemented multitenacny testing?
simpler implementation
ability to use existing rails migration tools
use of Postgres Views/Rules & Rails 3 scope to enforce
faster pg_dump, typical use case optimization in DB parser/planner for SELECT QUERIES
no need to jerry-rig IDs
no monkey-patching of Rails A/R (maybe just the connection)
Cons:
might break down at 20 to 50M records in a single table?
difficulty in partitioning?
These posts are over a year old, did anyone find out as to why to use the techniques in this episodes rather than the nest_form gem?
Thanks. What I was trying to do is not possible with Heroku at the moment: Sub-sub domains aren't possible on Heroku default domain (yourappname.herokuapp.com), and you need to use the custom record for that
http://stackoverflow.com/questions/17994288/subdomain-with-rails-and-herokuapp
I'm in the same boat. Adam or Matt could you please post if you found a solution? Thanks.
+1 for follow up. Baa.
+1
Hi Martin,
I have multitenancy setup as per this railscast and have just started to learn Minitest Spec. Would you mind sharing some of your testing code to show how you implemented multitenacny testing?
Thanks.
The pdf mime type is added by default in Rails 3.2: http://edgeguides.rubyonrails.org/3_2_release_notes.html
So you no longer need to tell Rails about the PDF MIME type with the following line:
Mime::Type.register "application/pdf", :pdf
In this blog (http://railscraft.tumblr.com/post/21403448184/multi-tenanting-ruby-on-rails-applications-on-heroku) the author recommends rows based multitenancy over schema based and gives the following pros and cons:
Summary of ROW-BASED Pros & Cons
Pros:
simpler implementation
ability to use existing rails migration tools
use of Postgres Views/Rules & Rails 3 scope to enforce
faster pg_dump, typical use case optimization in DB parser/planner for SELECT QUERIES
no need to jerry-rig IDs
no monkey-patching of Rails A/R (maybe just the connection)
Cons:
might break down at 20 to 50M records in a single table?
difficulty in partitioning?