I’ve always wondered what data structures are used by text editors to work with text so fast and smoothly, especially when the user is typing in the middle of a large document. I had already known about such data structures as ropes and gap buffers or splitting the document into smaller chunks (lines or paragraphs), but the implementation of a QTextDocument in Qt got my attention because it looked like the whole document content were stored in a huge continuous string:

class Q_GUI_EXPORT QTextDocumentPrivate : public QObjectPrivate
{
    // ...

private:
    QString text; // <-- the whole content, including tables and images, is indeed stored here :-)
};

The fact that this algorithm is absolutely undocumented and Google couldn’t find anything about it on the Internet, encouraged me to study the source code and write this blog post.

To remind, the N+1 problem means a code like this:

for comment in Comment.objects.filter(post_id=1).all():
    print(comment.author.avatar_url)

makes N+1 requests to the database (hence the name):

SELECT author_id FROM appname_comment WHERE post_id = 1;
SELECT avatar_url FROM appname_author WHERE id = 1;
...
SEELCT avatar_url FROM appname_author WHERE id = n;

despite only 2 requests were really needed here (not considering a single-request JOIN or nested SELECT for reasons that will be clear later):

SELECT author_id FROM appname_comment WHERE post_id = 1;
SELECT avatar_url FROM appname_author WHERE id IN (1, ..., n);

Indeed, it’s a well-known problem and Django offers a simple solution to it:

for comment in Comment.objects.prefetch_related("author").filter(post_id=1).all():
    print(comment.author.avatar_url)

But what if the “related” data isn’t stored in a DB table? For instance, if the user data such as avatars belongs to a separate service which is available over an HTTP API only.

I am upset every time I see a service calling another service when their business logic is not related to each other. Think about creating an entry in a security audit log or sending an email notification to the user once someone leaves a comment to their blog post. Calling these methods directly from a comment service would lead to a tightly coupled code which is hard to maintain and refactor.

A well-known solution to this problem is using aspect-oriented programming (AOP). However, you are usually limited to the original function arguments or its return value at most, having no access to the intermediate calculations. Before you try to refactor the code, introducing a new method just for a more suitable join point, let me show you another way first.

Unless you have a very simple UI, there are probably multiple views in your application, all having their own actions. The problem is, not all of these actions are disjunct – there are intersections, and we except to find some of them at particular places in the main menu or access over well-known keyboard shortcuts. The most obvious examples are copy & paste or delete actions, which are usually located under the Edit menu, assigned to standard key combinations (Ctrl+C, Ctrl+V, etc.) and sometimes put on the main toolbar. Creating individual actions for each view leads to multiple menu entries and shortcut conflicts, while creating a single action and managing its state and listening for its signals in individual views leads to complicated code and leaky abstractions. This problem can be solved using a proxy action, action multiplexer or context-aware action – an interesting pattern for Qt-based applications described in this blog post.