Someone asked me for the tl;dr about this, and I wrote the following: - The scalability limitations of flat XML files for storing thousands of builds or hundreds of thousands of Pipeline steps should be obvious, and they are a threat to the long-term sustainability of the project. - An embedded database can address many of these use cases without introducing new requirements on upgrade. - SQLite is the ideal embedded database. Though it has concurrency issues, these can be addressed by using multiple SQLite databases (think one SQLite database to store all the Pipeline build steps for a Pipeline run, another one to store the user database, etc). - Running Jenkins on SQLite is not a pipe dream. While a non-trivial project, it is within the realm of possibility, and it can be done retaining compatibility.
The Jenkins serialization API is object-oriented, and my prototype did not address the key point of adding an ORM (like Hibernate) with a session layer to manage caching. This would be essential for a full prototype, and implementing it in a backward-compatible way would be even more tricky. I stopped short of this, as it would take me well over one Saturday afternoon to put something like this together (starting by learning Hibernate from scratch). But on a high level it seems doable. With an ORM and a session layer one can start to think about replacing SQLite with a client-server database under the hood for more advanced installations. As others have implied, this opens the door to using e.g. Postgres as a warm standby in a high availability setup. -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAFwNDjo_FDejwnZ-xZ%3DzooJ9jqxRHo7LscpBYjr-mbkEixijRg%40mail.gmail.com.
