Sinatra Portfolio Project
--
This final project marks the end of the curriculum section detailing ORMs (Object Relationship Models), ActiveRecord, basic HTML & CSS, as well as sessions and forms.
I thoroughly enjoyed working through these topics and found my final project to be both challenging and gratifying. Writing this project from scratch provided the ability to take each piece of information I learned and structure it all together into a functioning application.
This project leaned heavily on the MVC (Model-View-Controller) structure and required functional CRUD (Create, Update, Read Destroy) actions.
My project contained two models — User and Painting. The User model had a has_many relationship to the Painting model and the Painting model had a belongs_to relationship to the User model.
Ideally, I wanted my user to be able to create paintings that would be added to a page showing all user’s favorite paintings, as well as have a homepage that would show only the logged in user’s created paintings. I also needed to have the ability to edit and delete the paintings.
I utilized the Ruby gem ActiveRecord when building out my application. ActiveRecord is a wonderful way to manipulate models whose data is persisted to a database.
To begin my process I first created two tables with the terminal command rake db:create_migration. This created two blank table structures for me to add in my table information. The blank tables reflected as such:
class CreateUsers < ActiveRecord::Migration[6.0]
end
class CreateUsers < ActiveRecord::Migration[6.0]
end
I then filled in the column information that my application would be utilizing like so:
When running rake db:migrate I ran into my first spot of trouble: nothing happened. I tried running the command a few more times but did not see any errors, new files created, or output of any kind.
I headed over to Google and began my search on StackOverflow, reading through pages of similiar questions: “rake db:migrate does nothing”, “Schema missing, rake db:migrate shows no output”. I tried several pieces of advice like “run rake db:migrate:status” and “try dropping all tables and re-creating your migrations”.
I decided to run “rake — tasks” to see what options were available to me.
I noticed the task for rake db:seed. I had created a file called seeds.rb with some dummy data at the beginning of my set up (for testing purposes) and decided to see if perhaps the seed data would load.
I added in a puts line at the very bottom of my seeds.rb file for “data loaded success” just to make sure I’d be able to see if it worked. It did not, but what I got was pretty useful: my first error.
ActiveRecord::AdapterNotSpecified: The `development` database is not configured for the `default_env` environment.
This finally gave me some data to go off of and I began searching high and low through Google. I reasoned that if the adapter was not specified then it must have something to do with how I set either my environment.rb file or my config.ru file. I thoroughly read through my curriculum section detailing ActiveRecord set up as well as the ActiveRecord documentation. I read through further StackOverflow posts and watched several youtube videos pertaining to databases and ActiveRecord.
Throughout my googling I came across the following: https://github.com/sinatra-activerecord/sinatra-activerecord
This served to be the key I was missing. I updated my environment.rb file to list:
set :database, {adapter: “sqlite3”, database: “development.db”}
and commented out my previous settings.
# configure :development do
# set :database, ‘sqlite3:db/development.db’
# end
When I ran rake db:migrate I finally saw the migrations run as intended and was able to move forward with building out my application.
Having the opportunity to see how the controllers function outside of lab work was a fantastic way to come to intimately understand how they are interconnected with the models. For example:
- The CRUD action for updating contains two methods. Below our get method sets the variable @painting to equal the painting object that is located by it’s id parameter and shows a view ‘paintings/show’.
- The view then accesses the painting’s name using the table column ‘painting_name’ and exposes it to the user. The painting’s year follows the same convention.
- Within the view above we have the ability to edit the painting, which is only available to users that are logged in — and to users that own the painting — by the logic written in the method below.
- The user is then routed by selecting the edit painting button to the edit view below.
This is just one example of how the model — controller — view structure ties everything in our application together. To view my full project code, feel free to check it out here.
