This post is some raw notes and is not very understandable by people who never worked with this code. In fact, the old implementation was so ugly that it was not simple even for me (who is constantly working in this area) to achieve this result. It needed many tries and reverts, but IMNSHO ended very well. Also, this was a large work that took many time, and I'm just writing some records here.

Back in 2006, just after being invited to take DSQL work, I started to think what would we need to do to improve the compilers (DSQL and BLR) internals. My look started at src/dsql/pass1.cpp and src/jrd/cmp.cpp. Till then, even the addition of a simple function was a nightmare. This dialog happened by Nickolay Samofatov and myself in September-2004:

Adriano: I added the "Lower" function. I don't knew that it is so difficult. "Length" will be added using blr too?

Nickolay: why difficult?

Nickolay: just fix 15 files or so :-)

So I spent some years fixing "15 files or so" to add each feature and became very bored. In v2.5, to implement ALTER CHARACTER SET and AUTONOMOUS TRANSACTIONS statements, I added a "compatibility layer" to implement statements in an more OO-way. I described the DDL work in this post.

As I had promised in that post, it allowed to implement subroutines, as well packages.

Within the v3.0 development cycle started, it was clear that not only statements was needing this layer, but expressions too. Expressions are much more "interesting" than statements. There are many types of expressions, all of them were mangled in the (now removed!) ubiquitous dsql_nod/jrd_nod structures and algorithms. These types are record sources, values, booleans, aggregate values, windowed values and lists.

The compatibility expression layer allowed to implement window functions (more here, here and here), but at the same time it create more ugly code in the (internal) interfaces.

The complete removal of jrd_nod was easy and done a lot of time ago. But dsql_nod remained. It was a lot of code needing a complete refactor (rewrite), which now is finally done.

This is the Node classes hierarchy. Except lists, each of them has its inherited classes (omitted here).

Node
--- DdlNode
--- DmlNode
------ StmtNode
------ ExprNode
--------- BoolExprNode
--------- ValueExprNode
------------ AggNode
--------------- WinFuncNode
--------- RecordSourceNode
--------- ListExprNode
------------ ValueListExprNode
------------ RecSourceListExprNode

As I said, much time was spent on this, but without it many other features were not possible (or viable).

It's easy to say now that the old code was a crap (and that is what it was, really!), but many things are involved here (like C vs C++, bison vs btyacc). The main thing is that this rework was now possible, so it was done.

Recentemente eu divulguei em meu twitter que estava fazendo sete anos do meu primeiro commit no projeto Firebird. Daí citaram isso no FirebirdNews e em newsletter da Firebase.

Estou dizendo isso porque apareceram algumas pessoas com aquele tipo comum de questionamento "Como entrar para o time Firebird?". O problema é que, como citado na newsletter da Firebase, desses sete anos pra cá nenhum desenvolvedor se juntou ao Firebird (core). Isso mesmo, com exceção de um ou outro patch específico (geralmente dos mantenedores das distros Linux), o Firebird é desenvolvido pelas mesmas poucas pessoas há mais de sete anos.

Sempre respondi esses e-mails, mas geralmente a "vontade" da pessoa já termina aí. E olha que sempre respondi com mais educação do que estou usando pra escrever esse post.

Então vou colocar o que realmente penso sobre isso. Em primeiro lugar, você não deve fazer essa pergunta "Como entrar para o time Firebird?". A primeira coisa é aprender a usar o Google e se surgir alguma dúvida que não tenha uma resposta, aí sim pergunte sobre ela.

É normal que você tenha dificuldade pra "se inserir" no projeto. Eu comecei a acompanhar o desenvolvimento do Firebird em dezembro de 2003 e meu primeiro commit foi em setembro de 2004, apesar de estar trabalhando ativamente desde junho ou julho. O Claudio Valderrama costumava dizer que eu era o único que tinha aprendido o código em algumas semanas, mas como podem ver foi alguns meses :), sem falar que até hoje eu não gosto nem de ver certos subsistemas (hello PAG, CCH, SDW...).

Outra coisa são suas habilidades. Não é normal que você não tenha no mínimo bons conhecimentos sobre C++, que é a linguagem usada no desenvolvimento do Firebird. Eu posso te afirmar com 98% de certeza que você não vai encontrar em um projeto open-source pessoas com vontade de te ajudar com coisas básicas.

Digamos que você já esteja pensando que não quer isso (como todos os anteriores), mas tenha alguma dúvida ainda, então continuo minhas sugestões para que você não consiga :). Não leia todos os posts das listas de discussões. Também não leia e tente entender todas as alterações feitas no código, que são enviadas pra lista firebird-checkins. Acho que foi aqui que falhei, pois desde aquele dezembro de 2003 não deixei de ler nenhuma das milhares de mensagens. E tenho certeza que todos os outros desenvolvedores ativos fizeram e fazem o mesmo.

Se você também se ofendeu com esse post (caso tenha sido um dos que fez aquela pergunta), é melhor não perder seu tempo e desistir logo. Quem acompanha as listas firebird-devel e firebird-architect (e a firebird-admins, mas essa é fechada), sabe do que estou falando. As vezes (pra não dizer, muitas vezes) as discussões partem pro lado pessoal, e isso é a pior parte de fazer parte do projeto. Isso não é uma exclusividade do Firebird. Comparando com o Linux, por exemplo, é só procurar alguma mensagem do Linus Torvals na lkml e ver como a coisa geralmente funciona.

In the old days, fonts in Linux were really ugly by default. There are patents involved, so it was possible to make them beautiful recompiling freetype with some options.

Since some time, this is not necessary.

But if you're like me, you may note that some fonts are very blurry in some applications, and you can't change that in the appearance config.

To fix this, I put this .fonts.conf in my home directory.

Saiu na edição 125 da revista ClubeDelphi o artigo que escrevi sobre as novidades do Firebird 2.5. Esta edição também tem outra matéria sobre Firebird, entitulada "Aplicações com Firebird Embedded – Parte 1".

The support for a BOOLEAN datatype was the third most voted feature in the Firebird tracker. The deal with it was about make it right and complete, having booleans expressions allowed where values are expected, and vice versa. Oracle did it wrong and they BOOLEAN is crap.