I am from UI/ColdFusion background, sorry if I am asking a silly question.
Let's say we have two models Book & Page and a book has many pages.
Normally i see rails devs do the below,
book = Book.find(id)
pages = book.pages
Which indeed executes two queries, one for getting the book and one for getting the pages.
Where as the same we can write like this,
Add a class method to Page model.
pages = Page.where(book_id: id)
This will execute one query but will still return the result.
But then why developers prefers the first approach instead of the second.
It's just the practice people follow
Usually, this scenario comes when you are accessing nested resources
book = Book.find(id)
pages = Page.where(book_id: id)
so to make sure you have the book available not just the orphan pages
pages = Page.where(book_id: id)
Whereas, with the above query you will get the pages even if the book is deleted, in case you don't have the dependent: :destroy for pages
From my practice, there are 2 answers to your question and the right answer would depend on the developer's experience.
Novice - Because that's how it was in the tutorials. The first Rails team I joined had a lead developer with no DB or SQL experience. He would not care or knew about the load on db server our code generated. This was quite common in early days of Rails (in my experience). ActiveRecords makes it so easy to forget that you have a DB in the background and it is easy to forget. Coming from java and php world myself, I would be asking why would we just write an SQL to join and do the heavy lifting on the server side.
Experienced - Experienced developers do it for the code readability. Because maintaining a readable code is cheaper in the long run. If your monitoring tools show that your DB server started to stress out, you can always profile and fix it (vertical scaling, adding caches on different levels of your architecture, etc). Also, when used in the controller, .find will generate 404 page if it can't find the record in the DB. Also, if you run your "custom" sql, you will lose "automatic" model-data relation maintained by AR for you. So, many choose to just do it that way.
So there you go. Unless you are working on very heavy load application, it is better to write a readable way.
Related
My friend has setting up a database for a Ragnarok Online server, and he wants me to code the relative website, which is going to use some of that data (and obviously, i'll have to add tables for the news system, website accounts, etc). Since i'm learning RoR i was going to do it that way.
I have a few "best practice" questions related to this :
Should I create a different database for the website, since it's going to have its particular data alongside the game data ? (i already have a few clues to link multiple databases with Rails, but that seems too much of a hassle for what it is).
If not, do i have to create Model/Controller for each of the tables composing the database, despite the fact that i'm not going to use 90% of it ? Or just the ones that i need ?
An example of this problem : the game database has its own "user" table, but i have to have another "user" table for the website, and do some Joins between those two. So, what's the best practice here ?
Uhm, best practice is not making your own user table. This will cause you much pain. Best practice? Use an API. Expose the game's database in some way to your website, and fetch that info with external requests in your web application.
The reason why making a second user table is a hassle:
1) You'll constantly have to update it, pulling data from the original
to keep it up-to-date.
And I mean furthermore, you're gonna have to create a CRON job or something pulling data from that original table to keep it up to date. Yuck. Also what if that CRON job makes a mistake? (It will)
2) It's almost inevitable that there will be inconsistencies if two
separate tables are maintained. Are you sure your web application is
really fail-proof?
Update:
What you're gonna need is essentially a second Rails application that acts as a REST API for that database. For a good idea of what REST is, I'd read through this to get you started: http://tomayko.com/writings/rest-to-my-wife
Once you have a good understanding of that, start making your app, and test if it's working by using tools like cURL to send requests to your API.
Once you have that done, I'd take a look into the Ruby rest-client gem like Nobita mentioned. This is what you're going to use from your web application to request information from your API application.
Just let me note, I think this would be a terrible first Rails project, unless you're already really well versed in other web development tools, preferably MVC frameworks.
Guys I am becoming completely nut on this...and can't figure out at all how come out of all this troubles.
I really need an holy help, or at least some suggestions about tutorial and guides about this problematic.
I believe that this is a very common task in many app, but I can't find nothing that help in this sense, not on stackoverflow, not on google, not on other rails forums that I know...I start to feel like a dumb!!!
Problem
(1) Models (the models that are involved)
User.rb
Item.rb (is nested in user: e.g. user/3/item/5)
(2) What I'd like to do
The current_user (the user that is logged in) can create an Item, and in the same form can decide to share it or no with many other users.
In this way, the item will be visible and accessible also for this users that we shared it with.
I understand that what is going to be involved here is:
(a) has_many :through relationship between item and user
(b) a joint table that we can call sharing (with item_id and user_id)
(c) eventually using different name for the user and use a :class_name to point to user
This is not hard to implement (and there are plenty of examples around).
What is really a mess, instead, is how build the controller (item controller), in order to perform in one shot, the creation of a new item, and the sharing operation (this means setting up the parameter in the joint table, and eventually create as many records as many users we are sharing with - array?)
And the other problem, that obviously is related with the controller, will be the view...how put all this in a single form, and allow the current_user to just click the button, and perform the item creation + the sharing operation?
Last thing, but not the least, how I need to deal with the fact that User is the same model of current_user??
I really don't know what I need to read or look up in order to let this work, I would love to see some example code,but at the same time I'd love to really understand the logic in all this, in order to be able to replicate it in other scenarios.
Please someone help me...I can't really move on in my app development without doing this, and this is also a crucial part of all the project.
Thanks so much for every small bit of help that I will receive.
Ok I have solved all my problems...that was not an hard task at the end (it's always easy saying that when you solved the issue:))
The only doubt that I still have is with the rails name convention:
Can be possible that using a name like sharing, for the joint model, that the final -ing is not very well handled by rails?
After many tentativeness performed to try to fix my problem, I discovered that everything was set up properly, and that just changing the joint table name from sharing to share, let the magic works!!!
First time posting in Stack Overflow, hope I'm doing this right.
I'm writing an app with Ruby on Rails right now. Without disclosing too much, the premise is that we have organizations and normal users. Organizations have events, which require users to answer a questionnaire before participating.
I'm pretty sure about these models / relationships that I will be using (this isn't really that important/pertinent to my question i think, but just wanted to give background):
organization (one to many) events
event (one to one) quesitonnaire)
questionnaire (one to many) users
(specific) response (one to one) user
The part I have a question about is how to implement the questionnaire. I want to give the ability to Organizations to essentially write / build their own forms. I'd like to stay away from them using code if that's possible (ie any DSL and whatnot).
I suppose the easiest way to do this is to give them a set number of text-area responses, so that I can consistently store the data and don't have to hassle around with how to configure storing this data (for example, maybe each event can only have exactly 5 responses to be filled in by textfield response by the user).
My ideal would be for the organization to be able to dynamically generate the forms on their own - maybe one questionnaire will have 1 text input, followed by 3 multiple choices, and maybe 2 short answers at the end; another one may have 5 multiple choices, and 1 short answer; yet another questionnaire might only have 1 text input...you get the idea.
So I see two parts of this problem - the first is the user interface for the organization to create the questionnaire. i'm imagining this wouldn't be terribly hard - ask them how many of each response type (MC, short answer) they would like to put into the form, give them the ability to rearrange them, etc.
The second part of the problem (what I'm more concenred about) is how to store/access this data. I'm guessing there's no dynamic-attribute sort of deal in ruby - storing some field with an unspecified number of parts and whatnot. i suppose i could make them all individual models (ie a question_response model, with :question, :response_type, :response, etc), but I'm fairly certain that's probably inefficient.
My initial guess is probably to serialize the data / use json; I worked briefly with Drupal 6 and this seems to be the way they did it. I was wondering if anyone else had any experience / suggestions though? I'm pretty new to Ruby so I was wondering if there's a gem out there or something that would help with what I'm trying to do.
Thanks!
You might want to look at the Surveyor gem
http://vimeo.com/7051279
*slightly old how-to video
https://github.com/breakpointer/surveyor
Surveyor does come with it's own DSL which is relatively easy to use (although can be abit restrictive at times). The data is saved as a set of question - answer values, so there is no actual specific model (beyond Surveys -> Questions (question_groups) -> Answers).
Originally I did look at having people submit their own Surveyor DSL specs - which would then be used to generate the actual survey via a Rake command.
I think if you need to build a dynamic model (and save the data) it is possible, although I am not not sure if you'll be able to get the Rake tasks to run to build the actual tables in a dynamic way due to permission restrictions.
Have a look at http://ruby-metaprogramming.rubylearning.com/ and Metaprogramming Ruby: Program Like the Ruby Pros by Paolo Perrotta, for some starters.
I am beginning work on a new Rails project that is based on the premise of allowing users to create their own "sites." Each "site" would be a subdomain of the root domain (we'll use example.com). So if user Foo wants to create his own site at bar.example.com, each page request to a bar.example.com page would require fetching the a row in a sites table based on the subdomain.
My question is not how to code a multisite app, I think I have a pretty good grasp on that. My question is, from a scalability and performance perspective, would it be better to simply generate a new rails project for each site a user creates? Or is it ok run all sites out of one rails app. If numbers are necessary, let's assume I have 1 million users, each with a maximum of 5 sites, with each site bringing in around 1,000 hits a day.
I realize this is kind of a broad question, and mostly depends on my implementation of either method to reach a feasible solution, but any suggestions in terms of the best way to write this, including optimizing the DB, etc. would be appreciated.
It would be exponentially easier to have 1 rails app with millions of subdomains compared to millions of rails apps.
Check out this railscast for how to start with subdomains: http://railscasts.com/episodes/221-subdomains-in-rails-3
I wouldn't ever consider doing something like this with multiple Rails projects, because of the need to maintain all the code. By keeping it centralized, you can change the functionality of everybody's sites at once.
I think you might also run into memory issues by having all of those copies of Rails instantiated, too.
#Solomon is right. Heroku.com is using same concept for it's users to demonstrate users' applications.
I have developed a fully functional ruby-on-rails application which utilizes numerous mysql tables. I would like to turn this into a subscription based service but I have some general, probably basic, conceptual questions:
In a setup such as Basecamp does each user have access to her/his own (as in unique) db tables or are the tables shared with millions of users and Identified by some variable?
If this is the case how well does it scale? What would be the best db to use (mysql, oracle etc)?
If each user is given his/her own unique db tables; how is this accomplished? Is it through a rake task?
Are there any resources you would suggest (books, media, etc) that explain how to accomplish either of these methods?
Thanks!
I believe it is achieved using an overall account. Whereby the resources in your current system will be scoped by that account. i.e in your index actions something like #projects = #account.projects. Looking at basecamp I would say it scales very well! If you hit this problem then you have a good problem to solve, don't worry about it too much until then. I should image the database is a cluster but very much doubt each user has their own set of tables, that would become a nightmare to manage!
A quick google and I've found a this: http://www.robbyonrails.com/articles/2009/01/11/subdomain-accounts-with-ruby-on-rails-explained which also links to a post by DHH which looks like it explains how they did it.
There are probably newer write ups but I'm guessing they would be a great place start.
Good luck!
The tables are shared and identified to a "parent" using a foreign key value. Having separate tables per-user would be a nightmare. It's more likely that good database normalisation fixes most of these issues. To-dos are related to projects, projects are related to an account and then each account has many users.
The best db to use would be entirely up to you. If you're using rails and db migrations, you're only limited to what that interface can utilise. To begin with, go with either MySQL or PostgreSQL (my preference). They're free and there's a wealth of knowledge available for hobby projects.
I personally would not create separate tables per user
Reading the wikipedia entries on database normalisation and database design would be a good start. Following that you should read up as much as you can on good database design, perhaps even starting with the common mistakes developers make when it comes to database design.