how to generate barcode in c# net with example $ rake db:migrate in Font

Printer QR Code in Font $ rake db:migrate

If you see nothing exceptional returned, congratulations! Rails can connect to your database. However, if you see something like this:

rake aborted! Access denied for user 'root'@'localhost' (using password: NO)

then you need to adjust your connection settings. If you re having problems, make sure that the database exists and that you ve entered the correct username and password.

Now that we can connect to the database, we re going to create a model. Remember that models in Rails correspond to database table names. Since we want to model events, we re going to create a model named Event. By convention, model names are singular and correspond to plural table names. So, an Event model will expect a table named events; a Person model will expect a table named people. Like most things in Rails, models have their own generator script that makes it easier to get started. The generator will automatically create a new model file in the app/models directory, and will create a bunch of other files to boot. Among these are a unit test (for testing your model s functionality, as we ll discuss in 9) and a database migration. A database migration contains instructions for building the database table and the fields to create. Whenever you generate a new model, a migration will be created along with it.

Usage: ./script/generate model ModelName [options]

As you can see from the usage banner, the generator takes a model name as its argument. The model name may be given in CamelCase or under_score format, and options

can be provided if you want to automatically populate the resulting migration with column information. Let s run the generator now to create our first model: Event.

app/models/ test/unit/ test/fixtures/ app/models/event.rb test/unit/event_test.rb test/fixtures/events.yml db/migrate db/migrate/001_create_events.rb

If you look at the lines that start with create, you ll see that the generator created an event model, an event test, an events fixture (which is a textual representation of table data that you can use for testing), and a migration named 001_create_events.rb. With that, our model is generated.

We need to create a table in the database. We could do this with a database administration tool, or even manually using SQL, but Rails provides a much more efficient facility for table creation and maintenance called migrations. It s called a migration because it allows you to evolve, or migrate, your schema over time. (If you re not familiar with databases, tables, and SQL, consult Appendix B for the basics.) Schema is the term given to the properties that make up a table: the table s name, its columns, and column types, as well as any default values a column is to have. And what s the best part about migrations You get to define your schema in pure Ruby. This is all part of the Rails philosophy that you should stick to one language when developing. It helps eliminate context switching and results in higher productivity. As you can see from the output of the model generator, it created a new file in db/ migrate called 001_create_events.rb. Notice that migrations are named with a numeric prefix, starting at 001. Since migrations are run sequentially, this number represents their position in the queue. Let s open this file and take a peek. It s shown in Listing 3-2.

class CreateEvents < ActiveRecord::Migration def self.up create_table :events do |t| end end def self.down drop_table :events end end

In its initial, generated form, the migration is a blank canvas. But before we go any further, let s note a few important items. First, notice the class methods: up and down. For each migration, you define instructions for updating in the up method, and use the down method to roll back any changes. So, if you were to, say, create a new table in the up method, you would drop the table in the down method, thereby reversing your changes. In fact, that s exactly what the generator did for us already: The events table gets created on up and dropped on down. Pretty slick, isn t it

Note You can easily spot the difference between class and instance method definitions in a Ruby class