Today I learned a MySQL term: online DDL.
The online DDL lets you alter tables efficiently, without making tables unavailable during the entire operation and exclusive table locks. The behavior of a DDL operation can be specified using the ALGORITHM and LOCK clauses. You don’t have to get overwhelmed by the mysterious terms. Actually, you may have used it before without knowing because MySQL will try to use it by default when you execute ordinary alter table statements.
Today I learned that when doing database-migration on Rails, change_table :#{table_name}, bulk: true let us combine multiple alter-table statements and it could reduce the cost of the whole alteration. That is, instead of executing multiple alter-table separately,
def change add_column :users, :first_name, :string, null: false add_column :users, :last_name, :string, null: false end we can run a single alter-table statement by change_table like as follows.
def change change_table :users, bulk: true do |t| t.column :first_name, :string, null: false t.column :last_name, :string, null: false end end However, why should we do that? What are the differences between them?
Today I learned that RSpec’s #to method takes the 2nd argument as its custom failing-message.
expect(actual_value).to eq(expected_value), message Let’s say we are going to test a JSON object. The following example expects a part of the JSON object response_json['eye_colour'] to be "blue".
require 'net/https' require 'uri' require 'json' RSpec.describe do example do response = Net::HTTP.get_response(URI('https://swapi.dev/api/people/1/')) response_json = JSON.parse(response.body) expect(response_json['eye_colour']).to eq('blue') end end Unfortunately, this test fails and displays messages like this:
Failures: 1) is expected to eq "blue" Failure/Error: expect(response_json['eye_colour']).to eq('blue') expected: "blue" got: nil (compared using ==) From this output, we could guess either response_json['eye_colour'] is set to nil or the key eye_colour is not defined. However, there is no more information here. To find out the cause of the error, an additional print-debug would be needed.
Today I learned how to fix a PostgreSQL error like this:
ERROR: canceling statement due to conflict with recovery DETAIL: User query might have needed to see row versions that must be removed. It’s about database replication. I have been getting that on read-only database which uses PostgreSQL Hot Standby. This error didn’t happen always but happened occasionally.
I fixed that by setting both max_standby_archive_delay and max_standby_streaming_delay to a longer time (300s) on the standby servers. The reason that this error occurs is query conflicts. This kind of error is not inevitable because of the nature of database replication, and in some cases, queries running on standby servers have to be canceled. Then the error shows up.
Today I learned that Rails 6.1.3 does not have methods that raise exceptions when more than one record was found. However, in future versions, we could use ActiveRecord::FinderMethods#sole for that purpose. It seems Enumerable#sole is also going to be introduced.
Sometimes I need to make sure there is one and only one record that matches a condition without using a unique-index, for example, when I cannot add that constraint to the database.
