June 23rd 2020
Physicist and geek trying to write. Currently going into the world of code with passion.
Ruby on Rails has many in built methods, it’s in its nature; at some point it can create some sort of stigma due to its, well known, slowness performance, but several of those methods already can help you to write a clean and faster code.
That means that the Active Record interactive interface let’s you structure, modify or retrieve your data in Ruby instead in the app’s query language, receiving newly instantiated Ruby objects of the model that corresponds with the query.
The query methods only read and / or order the data, falling into the next descriptive categories:
- Retrieve single objects.
- Retrieve multiple objects.
- Use conditions.
- Return specific number of objects.
- Return a specific categorization of object.
- Order data.
Let’s analyze a few methods.
Single objects methods.
One the most recognizable features about the single objects query methods is that they retrieve a row of a database table, in other words, a single object.
Multiple object methods.
The multiple objects methods have the characteristic of retrieving all the data encapsulated inside a database column. Thanks to the big amount of information that this methods manage, some of the most interesting pieces of code inside your data model belongs to this category. Let’s see some of them to understand why.
Conditions in queries.
The syntax of the image example for the where method shows us an array passed as a parameter, but there are several other class objects that can be passed too, the important thing to notice is the and word, that builds up the condition as a logical one. In fact, what we are passing as a parameter in the first picture is exactly the same as in the picture below, a selection for an strictly existence of the two attributes, the name John AND the surname Doe.
Specific number of objects.
A code like the one in the picture above will return ten articles starting from the tenth position. If no offset is declared, the retrieved data will include only the limit specified objects starting since the first position stored.
Specific categorization of object.
The scope differs from a normal class method in it’s safety, the first one will always return a relation, whereas our simple class method implementation will not and can break the chain ability, plus, if you have a relation you can access to it’s data, directly from the view or the controller, without writing more code.
As it’s shown in the image, for declaring a scope you: First of, name your scope, then, write the parameter / attribute to pass and the block that manipulate the passed data.
For invoking your scope / scopes, you chain them to your data table object and pass the parameters that you need. You see? The logic for declaring and invoking a scope is really similar to the one you follow for declaring a class method. For more implementations, let’s go to the next section.
In the first picture we see a simple ordering code, where the order method accepts a parameter, this parameter can be an attribute, a string and a column name. If no direction of order is specified, the ascending order will be applied by default. For specify this order direction you can see the next syntax:
Another alternative is to declaring a named scope and call it from the view, like in the pictures below.
By implementing this logic, you’ll reduce the amount of code you write but, so far so good, even when we saw many important shortcuts, that’s not all, we learnt before that manipulating the data directly from the model it’s a best practice, but it’s not a good one assign it in the view.
Calling the database query it’s one of the most expensive parts for Rails, the instance variables are set with all the object’s information one and only one time: When they are created in the controller, this means that you are accessing to the database only one time for each object, and compared to the scope called from the view, where the database is invoked every time you use the query method, the assignment in the controller is considerably more optimal. In order to use that already-invoked data you should do all the assignment work in the controller, where you are declaring your instance variable, like in the example below:
This implementations will lead you to optimize your code, to apply the best practices, to be prudent at the moment you plan your Rails app and to built your own Query Interface taking in count the diversity of the query methods that Rails have and the features of your application. Let’s go and try it!
Or deciding if you need to use the database:
It always depends on you, choose reasonably.