Rake Not Creating Tables - ruby-on-rails

Question

Problem
rake db:migrate is not creating tables in my MySQL database. (Yes, I have read all similar posts, and implemented their suggestions, please continue reading.)
Code
database.yml:
default: &default
adapter: mysql2
encoding: utf8
pool: 5
username: root
password:
host: localhost
port: /tmp/mysql.sock
development:
<<: *default
database: asreport
Line from gemfile (yes, I already gem install'd it too):
gem 'mysql2', '~> 0.3.20'
/appfile/db/migrate/create_users.rb (I've also tried making the second line 'def up'):
class CreateUsers < ActiveRecord::Migration
def up
create_table :users do |t|
t.string :username
t.string :password
t.integer :usertype
t.string :salt
t.timestamps
end
end
end
After I run rake db:drop, rake db:create to refresh, rake db:migrate --trace reads (after this output, 'show tables' in mysql still only shows schema_migrations):
** Invoke db:migrate (first_time)
** Invoke environment (first_time)
** Execute environment
** Invoke db:load_config (first_time)
** Execute db:load_config
** Execute db:migrate
** Invoke db:_dump (first_time)
** Execute db:_dump
** Invoke db:schema:dump (first_time)
** Invoke environment
** Invoke db:load_config
** Execute db:schema:dump
What I've Tried
First of all, I know that I am connecting to MySQL via Ruby, as db:drop create does indeed create the database itself, just not the table.
I've read all the relevant stack overflow posts I could find on the issue. I've tried rollback, dropping my database directly on SQL, and db:drop/create.
I've tried deleting and recreating my migration script too.
I've run db:migrate multiple times (by itself and after db:drop/create's, rollback's, resets), but the schema_migrations always has 0 entries and my schema.rb file is on version: 0.

Answer 1

You're not following the naming conventions outlined in the Rails Guides.
Specifically, this:
2.1
Creating a Standalone Migration Migrations are stored as files in the db/migrate directory, one for each migration class. The name of
the file is of the form YYYYMMDDHHMMSS_create_products.rb, that is to
say a UTC timestamp identifying the migration followed by an
underscore followed by the name of the migration. The name of the
migration class (CamelCased version) should match the latter part of
the file name. For example 20080906120000_create_products.rb should
define class CreateProducts and
20080906120001_add_details_to_products.rb should define
AddDetailsToProducts. Rails uses this timestamp to determine which
migration should be run and in what order, so if you're copying a
migration from another application or generate a file yourself, be
aware of its position in the order.
Go ahead and try a dummy migration to see the file name convention.
$ bin/rails generate migration AddPartNumberToProducts part_number:string