What is t.string :first_name

I assume you're looking at the "[random number]_devise_create_users.rb migration

I know that this tutorial in particular is letting "Devise" do all the work here for you. You aren't making an iteration for each user, though the syntax is very similar to what you might see in your view: "Users.each do |user|" essentially the "do |t|" is doing is just creating a container to put some code in. ".each" is doing it for each iteration. However, this is a single iteration and the iteration is not a user, it is the table you're putting users into. I think a good way of visualising it is to open up something like Microsoft Excel. You've got a spreadsheet and you want to have all of your users and their information listed in that spreadsheet. So you have this first row that you want to fill with the headings, "First Name" "Last Name" "Profile Name" "Email Address" "Password". However, we need to restrict what kind of data we put in (which you can also do on Excel), because let's say, we wanted to store a user's age and then wanted to calculate the average age of our users. It would be useless to us if a user puts in "twenty seven" as their age, because the computer wouldn't know how to translate it into a numeric value. This is where t.string comes in. In my "age" example, it would be t.integer so the person has to enter "27" and not "twenty seven". The best way to think of 't.' is 'table'. So in this table, we want to add a column with a string string called "first_name" t.string :first_name.

But what's a useful resource for understanding data? I would saying anything related to SQL. What writing migrations is doing is allowing us to write to our "schema" which is used to make the rules for our SQL Database. To see what's generated, look at schema.rb. But the actual code is serving as a middle ground between us and our SQL Database, because we're writing Ruby code and not SQL code and the advantage of working like this is not only that you get to stay in the Ruby frame of mind, but you get to use Ruby variables when you're trying to get data instead of writing SQL queries. Ruby on Rails will handle the query for you. You can actually see it do this when you've got your console running your rails server, you might see something like: SELECT "users".* FROM "users", which is a SQL Query that Rails is doing for you. So a good place to look to try and understand what Rails is doing is to maybe pick up on some basic SQL. I actually find it helps when I am writing Rails code, because I am able to treat my variable not like standard variables, but get in the frame of mind that I am writing for SQL, for example, I might use the line, Character.where(user_id => current_user).all In my situation (as I've been coding a site for roleplayers), a user will have many characters, so this allows me to find all of the characters belonging to the current user. I thought to do this, because I know SQL uses a WHERE statement. In my log, the matching SQL statement comes up as: SELECT "characters".* FROM "characters" WHERE "characters"."id" = ? LIMIT 1 [["id", 4]] In lay mans terms, "get me all characters from the character table where the user id matches '4'" (4 being the id of the current user).

Unfortunately I cannot see anything SQL Databases on this site, but really, I think a basic understanding is beneficial. Instead, what I did was pick up a book: http://ineasysteps.com/products-page/all_books/sql-in-easy-steps-3rd-ed/ This one is dead simple and covers the basic ground you'd need. You may not need to write a single line of SQL code, but personally, I like knowing what Rails is doing for me so I know how to manipulate it to do what I want it to do. :P

I hope that this is helpful.

Hi Thanks! This is very helpful.

I know a little bit on the SQL, so I get the SELECT, FROM, WHERE part.

I guess I will think of t as a row and each one of the :first_name stuff as a column. I was not sure why the convention :followed_by_something was used. I felt like that was explained somewhere on this site, but maybe not I guess it is the same as the attr_writer convention, but I have a hard time keeping that all strait.

I really like the idea of understanding what is going on because when you leave the script you get in a lot of trouble if you don't understand what is going on.

Thanks!