Hi there! Previously I have written about this project on my personal blog. Back then I called it “database”. So from web site url you can gues that something was changed since the end of the 2020.

On Naming Things

Most of people know that naming is hard. IsomorphicDB has its own experience. First eight-nine months it didn’t have a name . Back in January I started to thinking about how to name it. That was fun time especially when I couldn’t get rid of thought of “oxymorondb” - because it was database that couldn’t save data Then I thought that subjects like chemistry could help me. Words like isomerism and isotopes led me to isomorphic. Isomorphic means to have the same or identical form or shape. I choose it because I liked it - this is it, there is no any logic behind this decision.

On Separate Website

After giving a name I desided to create separate website for project. For now it will contain user documentation about IsomorphicDB, you can check Getting Started page, and for publishing blog posts, similar to this one.

On Query Plans

Somewhere around end of January new implmentation of Query Engine was merged. With previous approach IsomorphicDB tried to do multiple things at one time with SQL expressions. It was one code that did type inference, type checking, type coercion and evaluation of an expression. With new approach it was split into four different peaces and evaluation of expressions moved into query plan execution. If you are familiar with databases and their internals current implementation of is similar to physical query plans. This means that there is no any optimizations during query execution, IsomorphicDB translates sql query in direct data reads and writes over tables.

On Where Predicates

Implementation of new Query Engine took about three to four of months. However, one of the plesunt side effects was that evaluation of where clause was implemented in couple of hours for all three posible queries: SELECTs, UPDATEs and DELETEs. Before that I had no much ideas how would it be possible to implement properly.

On Adopting RFCs

Since the beginning of working on the project I faced problems. I could switch between code and modify it in not much structured way. I could work on network connection if I touched code that is used by Query Engine changes could trigger domino effect through most of the modules. That could lead me jumping around and submitting PRs mostly in random way for different modules. Since the end of April I decided to follow RFCs process. Not that I will comment on my own PRs of RFCs documents but still I want to address couple of problems:

1. There is no documentation for contributors or external developers
2. I feel like complexity of project is huge and I don’t want to create issue and simply put “good first” label on it without description or references to some documentation
3. I didn’t (maybe still don’t) have answers on possible contributors question “How do you see it implemented?”
4. Whenever I want to change some part of the database I would like to start with laying down my thoughts about changes
5. Writing ideas out triggers to go and explore. Writing prototypes helps me understand the scope of the problem
6. With implementation of my first RFC I noticed that I am more concentrated on the particular modules or place in the code

On Future Plans

One more plesant side effect from adopting RFCs is that now I have much clear plans for the future that you can see here. In nearest term I want to finish my work on multiple queries per transaction also lay down RFCs on in-memroy storage format and proper lock-free transaction implementation. Also I have more far-reaching plans but I feel it requires a separate blog post.

In Conclusion

In the beginning of the project I was able to publish at least one post per month. I would like to be back so I will setup an alarm on my mobile phone to remind me to write a blog post what is happening with IsomorphicDB. Thanks for reading and hope to see you in June