We have an admin application used to manage member data and it was built in 2.1, has been running for about a year. Now that all inputs and data massage is done, our client wants to start building member site, members will have access to data the administrators have been inputting.
Here's the question, should we start a new Rails app hooked to the same admin database or should we create a new Rails app in different db with master-slave settings? The good thing about creating a new Rails app is obviously taking advantage of the new version, which we like. Or ..maybe just build the member site in the same admin app?
THanks,
Why don't you want to build the member site in the same admin app? Too much legacy?
You can use the same database but the problem is you will have to enforce any conditions you have in your models directly in your database (mandatory fields, model relationship and so on).
And I can see a lot of duplication code happening between the two apps. At least for the models. Which is really wrong :(
I don't recommend making two separate applications but It is hard to answer without looking at your app and without knowing more details.
Or build a new app using a copy of the existing database?
There's no reason the two applications cannot share the same database.
However, there's probably a number of reasons why they shouldn't. But, the only way you're going to figure those out are by going through the changelog of ActiveRecord's database adaptors.
Related
I'm a bit of a Rails beginner, so I'm sorry if this question is easy. I'm wondering how I am supposed to modify the Rails database as a developer without letting users of the site modify data.
More information:
Let's say I am trying to create a website that lists books along with their information. I want users to be able to see these books, but not add/delete them. As a developer, I want a way to add books without using the command line (hard to edit mistakes). What's the easiest way for me to do this? Would there be any differences between the development database and a live hosted one?
I think there are a few approaches to do this.
different user roles. This technically breaks the rule of without letting users of the site modify data, but being able to differentiate between normal and admin users means you can limit who actually can add data into the database. I used cancancan as a way to authorize requests but I know there are others.
I agree doing it using the command line isn't ideal, but rails do support rake tasks. You can create a task that will handle most of the logic and all you need to do is something like
rake create_book["name here"]
This will make the process less error-prone.
Create data using rails migrations. Rails can generate the skeleton file for you, and you just ran any ActiveRecord methods. However, the main purpose of migration is to update the database schema, but they can seed the database as well. here's the example from the dcos
Would there be any differences between the development database and a live-hosted one?
Yea, they should be totally separate database instances. You don't want to have your development database be the same as the live one. This would cause major problems. Rails have a concept of environments where you can use different configurations, so you can pick and choose what database URL to use.
like #davidhu said here The best approach really is the use of authorization. If only admin can see a page to CRUD the books then you don't have to worry about normal users doing same plus it makes it easy for you as the admin to make changes or add to the collection. Add the gem (or reinvent the wheel) then Rails will take care of the rest for you.
I've built a database in Neo4j and use Rails with Neo4jrb as an easy way to manipulate the database. For reasons I explain below, below I call this a knowledgebase (kb) instead of database.
I starting working with a friend who wants to provide access to the kb for users of his app. So I built an API in rails so he can access it.
Now my friend and I are talking about building a membership site with subscription payments. So I figured I needed to figure out how to build Stripe subscription payments into my app. I found this great tutorial by RailsApps which in terms of functionality does exactly what I need, it relies on a gem called Payola which makes Stripe integration easy. Payola is great but it works with ActiveRecord, not Neo4j. I was thinking I'd have to figure out how to do what Payola does with Neo4j.
But now I have the idea of just building a separate app using the RailsApp+Payola approach, and then just hooking that app up to my kb's API.
The reason I say knowledgebase is because its purpose is to structure knowledge within a particular domain. I use the graph database Neo4j because the graph-based data model suits this goal, for example (object of type A) -[has a certain influence on]-> (object of type B).
So I like my idea of using a separate app for managing users and subscriptions because then I avoid mixing app specific data with domain knowledge in the database.
So I guess my concern is, what might I be missing? Will speed be a concern if this membership site has to access an API every time a page loads? Would there be unusual security concerns?
It's perfectly fine to use another database next to neo4j. You should always use the database that fits your needs I think :)
I have a rails 4 app that exposes API to external users. The users also get access to a web dashboard where they can see & manage data related to API calls, similar to stripe. Stripe dashboard also allows you to switch between live & test data. I am looking to replicate similar behavior. Are there any design recommendations or a Rails way on how to do this? Use separate database (db_live vs db_test) or use separate tables inside db_live, and then use *_test table naming convention to access test data inside live database.
Whats the Rails/ActiveRecord way to do this? I am using Postgres as the database.
One potential solution would be to simply add a live (or test) boolean column to the appropriate database tables and use scopes to apply the desired where condition. An index on the column would also help with performance.
The practicality of this solution depends on exactly how test data is generated and how much of it you expect there to be per user/account.
Was searching for the same answer as well. Till now, the best option I can think of is to use a multi-tenant system. You can set a session variable as test|live and based on it connect to different databases OR in case of postgres different schemas. This way, all our code will remain DRY and all the switching logic between test and live systems can be moved in a single place.
Here's a basic idea on multi-tenant systems:
http://jerodsanto.net/2011/07/building-multi-tenant-rails-apps-with-postgresql-schemas/
I have two Rails applications, let's call them A and B. A has existing user base and i want these users to be able to log in to B with the username and password managed in A.
B is altered version of Altered Beast forum and it would be nice if users of my application do not have to create another user account to use forum. My initial thought was just to swap out the User model with ActiveResource model. Forum is hosted on a different server so direct database connection to A's database is too much trouble.
My question is that is there any plugins or authentication system extensions that handle this kind of setup.
Altered Beast uses the restful_authentication plugin. Could you not just use the same plugin in application A pointed to the same database?
Edit:
Use a cooooooookies from application A.
It's an application that we use internally at the office that I would like to offer as a hosted service for anyone.
How can I do that without making major code changes?
The first thing that occurs to me is to have the app select which database to connect to based on the domain.
So each instance of the app would have its own database, but all instances would share the same code.
The only changes required to the code would be the database selection.
Is this approach maintainable? I've heard wordpress.com does this and that it offers a couple of advantages. I'm mainly looking to do it this way to avoid have to scope my entire set of database queries to a certain site within the same database.
Thanks!
The simplest way to do this is to clone the application, and create another server instance to handle it. This actually the way I handle multiple wordpress blogs on my server
Pro:
This process can be streamlined into a utility script.
Can be easily maintained if symlinks are used for the common code. IE: Everything but branding and some of the things in the config directory.
Cons:
- If you're using passenger it will require an apache restart for each new instance.
- Same if you're using Apache to route subdomains on different virtual hosts to different mongrel clusters.
However the better way comes from the question: Rails - Separate Database Per Subdomain
The method in the accepted answer is much more robust. It might require more changes than you're looking for, but it has all the benefits without the drawbacks of any other methods. Each new instance requires a new entry in the master database with the table name and other instance specific information. You'll also want custom rake task to build the database for each new instance.
I would suggest switching the database connection and adding a view_path based on the domain, I have posted code in this question.
I hope this helps!
I wouldn't do this with multiple databases as you mentioned. Keeping all your schemas/migrations in sync with all the db's could become painful.
I would look into simply making it a multi-tenant app where you have some sort of "Account" model and then all your existing models are scoped to it ... in other words, if this was a blog app, your Account has_many :posts, etc.
With this approach, you can identify accounts by subdomain ... have people choose their subdomain when they create an account and go from there.
It's pretty straightforward to do. If you need add billing into the mix, you might look at the SaaS Railskit (which handles all the signup and subdomain stuff) or Chargify.
You can also identify accounts Twitter-style ... with http://myapp.com/someuser