After publishing recent blog posts about table partitioning - its SQL basics part and how to use in in Rails application I was asked quite a few times what is the real performance gain when using table partitioning. This is a great question, so let’s answer it by performing some benchmarks.
In the previous blog post we learned some basics about table partitioning: how it works and what kind of problems it solves. So far we’ve been discussing mostly basic concepts with raw SQL examples. But the essential question in our case would be: how to make it work inside Rails application then? Let’s see what we can do about it.
You’ve probably heard many times that the database is the bottleneck of many web applications. This isn’t necessarily true. Often it happens that some heavy queries can be substiantially optimized, making them really efficient and fast. As the time passes by, however, the data can remarkably grow in size, especially in several years time which can indeed make the database a bottleneck - the tables are huge and don’t fit into memory any longer, the indexes are even bigger making queries much slower and you can’t really optimize further any query. In many cases deleting old records that are no longer used is not an option - they still can have some value, e.g. for data analysis or statystical purposes. Fortunately, it’s not a dead end. You can make your database performance great again with a new secret weapon: table partitioning.
Is validation in your models or form objects enough to ensure integrity of the data? Well, seems like you can’t really persist a record when the data is not valid unless you intentionally try to bypass validation using
save: false option when calling
save or using
update_column. What about uniqueness validation?
A classic example would be a unique
I was recently asked what is
secret key base used for in Rails applications and why not secure value of it (or even worse - the public one!) creates a security issue. That was a really good question, I remember how it was a serious threat years ago, especially before introducing
secrets.yml in Rails 4.1 - at that time by default
secret_token initializer was generated and the secret key was directly stored there. The result was that in many open source projects secret key was publicly available creating a great security risk. Let’s take a look how exposed secret key base could be exploited.
Ordering with ActiveRecord and PostgreSQL may seem like an obvious and simple thing: in most cases you just specify one or several criteria with direction of ordering like
order(name: :asc) and that’s all, maybe in more complex scenarios you would need to use
CASE statement to provide some more customized conditions. But how could we approach sorting with forcing blank values to be the last ones, regardless of the direction of the sort? You might be thinking now about
NULLS LAST statement for this purpose, but that’s not going to handle empty string. For this case you need something special: time to meet
NULLIF conditional expression.
In my recent post I mentioned some strategies of handling non-strictly CRUD / RESTful actions in API. One of them was adding extra actions beyond creating, updating and deleting resources. As it’s not a standard solution and some data layers on client side (like Ember Data) don’t handle it out-of-box, I was asked by some developers what’s the best way to handle such actions. So let’s see how can we hack into Ember Data and make it smooth.
If you happen to develop API for non-trivial app with complex business logic beyond CRUD directly mapped to the database tables (i.e. typical Active Record pattern) you were probably wondering many times how to handle these cases and what’s the best way to do it. There are quite a few solutions to this problem: you could add another endpoint for handling given use case, add non-RESTful action to already existing endpoint or you can add a magic param to the payload that would force non-standard scenario in the API. Let’s take a closer look at the these solutions and discuss some advantages and disadvantages of each of them.
Having some kind of
type attribute in your models is a pretty common thing, especially in applications with more complex domain. How do you handle such cases? Is it with multiple conditionals /
case statements in every method dealing with the type attribute? If you’ve been struggling with organizing and maintaing code for such use cases then say hello to your new friend: type delegation.
In the previous blog post we were exploring a new wonderful feature coming with ECMAScript 7: decorators. This time we are going to learn about
async / await, which is at this moment at Stage 3 in TC39 process, which means it’s already a release candidate that passed Proposal and Draft stages. Just like decorators, it’s already available in Babel. Let’s see what kind of benefits does it offer.