The C-Files: F1_01: Associations and Active Record (INAUGURAL POST!!!)

As a coding novice, I have become familiar with creating unique classes that have associations with one another. Classes will often times have unique behavior, that, depending on the aims of the programmer, will require one to write specific methods, or inherit them (but more on that later).

Take for instance a (not for an application) domain that includes three models; an Artist, Song, and Genre.

If you were going to be programming methods for either of these classes, you would need to know whether or not a relationship exists between them. I feel personally that it helps to put things in a “real-world” perspective. Putting these classes in a real-world context, I find, makes it much easier to see what kind of relationships exist between the three.

Normally, you would associate an artist with a song and a song with a genre. So right away in programmer terms, you could say that a song “Belongs to” an artist. The same kind of relationship would exist between a genre and song, meaning a genre “Belongs to” a song. What’s more, is you would realize that an artist has likely made several songs. You could say then that an artist “has many” songs.

But what about an artist and genre? Does a relationship exist between them? Well it would be weird to think about it in terms of an a genre belonging to an artist, because in the real, most artists (unless they are exceptionally unique) do not have a monopoly on one genre of music, so it wouldn’t make sense to say a genre “belongs to” an artist. But, it would also be foolish to suggest that there is no relationship at all between an artist and a genre. We just cannot say that either belongs to one another directly. This is where a “Many-to-many” or “Has-many-through” relationship would make sense between our models.

If we want to make apps where different classes/models interact with each other, we definitely need to know what kind of relationships exist between them. This is because often times, models may need to access information about other classes. In our example, let’s say an artist wanted to see what songs he, she, or ze has made. The method “my_songs” for the Artist class would do just that. This method goes into the array of all instances created for the Song class, and retrieves instances where the song(artist,…) is the one for a specific Artist instance.

In order to retrieve the genre, however, things get a little trickier. First you would have to get the list of all song instances associated with the artist (which we did with my_songs). Then in order to get just the list of the genre names, you would need to enumerate inside of my_songs further in order to retrieve that list.

While it is cool to be able to go about things like this, there are some definite cons to this approach. The first being that we are not using a database, ergo we cannot save instances of classes as data that can be stored and retrieved later on. Another problem being that in order to access what would be considered kind of trivial information about an artist, (i.e. what genres they work in), it is annoying to have to write methods that involve enumerating multiple times to get to that information. It just seems inefficient and impractical.

Luckily we have databases, and if you’re working in Ruby, you have ActiveRecord! ActiveRecord would make our lives much easier because in this case you can associate an artist with a genre without having to write any methods. ActiveRecord(::Base) when inherited by the models for Artist, Genre, and Song, can associate models when you define their relationships. We are keeping the same relationships in tact, even though they look different as you can see. They are being declared in the way that ActiveRecord needs them to be in order to run correctly.

ActiveRecord works its magic by interfacing code written in ruby with a database file. We can create instances of Artists, Songs, and Genres and store them in a database file, that we can then modify and update if necessary. We can also change or add to our methods in each of our models without breaking anything. Pretty great stuff!!!

Back to our example, let’s say after creating a SQL database with ActiveRecord, and associating our models in the proper way, that we want to find out what genres an artist is working in. Writing that method, here as get_my_genres, becomes as simple as a…

self.genres

This would return a list of whatever genres an artist is working in, like saw earlier. Under the hood, ActiveRecord has taken care of storing instances of classes for use in an actual database, so I don’t have to initialize an

@@all = []

which would store instances of classes

and I don’t have to create a method that creates a reference to the instance.

def

self.all

end

That data lives in a database file which we are accessing with our models.

By using ActiveRecord, there is no need to enumerate, because the relationships were declared and just needed us to populate our database with the info from each instance we created. Much less cumbersome than having to write out those enumerable methods, which to be honest, can get confusing to look at sometimes!