For the last couple of months I’ve been slowly going from Python to Kotlin. Kotlin is a statically typed language running on JVM. During the last years I was rather avoiding all the JVM stuff. Now I’m slowly starting to appreciate this.

I always disliked Java for the huge memory consumption, garbage collector, the terrible inconsistency and quite stupid design decisions. Then I slowly switched to Python. It was great at the beginning. However, when going deeper and deeper, and the projects were getting bigger and bigger, it turned out that it’s just slowing down the whole development.

SQL has a little bit different logic system than normally is taught at schools. The simple two value logic has only the values: true and false. Additionally there are logical operators like or, and, not. There are also operators returning these values like =, <>, in.

All that combined allows for some complicated searches like:

SELECT * 
FROM tab
WHERE a = 'b' AND (x <> 'c' OR y in ('a', 'b'));

An example from the last bug I fixed:

SELECT *
FROM x
WHERE id = :id1 AND id <> :id2;

The values of :id1 and :id2 are passed by a function using a complicated logic. Generally I wanted to have results like this:

WITH DATA AS (SELECT 1 AS id)
SELECT id
FROM data
WHERE id = 1 AND id <> 2;

 id 
----
  1
(1 row)

For some values of the :id2 argument the query returned no rows at all, even that there was a row with id=1.

The two-valued logic in databases is generally useless. In SQL there is something more: there is NULL. This is also called a three-valued logic. The rules are a little bit different and sometimes it’s too easy to make mess.

The Boolean Values

In the two-valued logic we have only true and false. Then the results of some operations are:

There Was an Error in a Good Query

After applying a data migration we had some duplicated rows in a table. I wrote a simple query for finding the duplicates and removing them from the table. All went fine. Or at least I thought so.

This kind of operations should always be done in a transaction, so the changes can be rolled back on error. The general workflow I use looks like this:

BEGIN;

DELETE FROM x...

SELECT * FROM x...

...

This leaves an open transaction, so I can check all the data without modifying them permanently in the database.

After writing the Part 1 and the new Part 2 of the Virtualenv Tutorial, I have created a simple video showing how to install the Virtualenv Wrapper on a fresh Ubuntu installation and how to create the first virtual environments.

Some time ago I was using the Records library. When I searched for some comments, I noticed only good reviews. The main goal of this library to simplify things. It’s a proxy to the SqlAlchemy library.

The only thing I was no impressed with was the library interface.

After some time of using it, I got the feeling that the interface is not good enough. It looked rather like some random ad hoc bunch of functions put into classes.

So I have decided to implement my own version. Mainly to find out if it is possible to create the kind of interface I described here.

That’s why the DBRows Project has been born.