 Yeah, you need to put the mic on. Yeah, do you have the mic on there? Yeah, please put it on. That's fine. So I put it on my neck. Does it clip that onto your top there? Just like that. Okay. So is it working? Is it working? Okay, thanks. So, may I start? Okay. Hi guys. My name is Tamás Punt, and I was working on LibreOffice for three years from now, and now I am a contractor at Collaborar Productivity. The main topic I would like to talk about is LibreOffice base. Maybe it's not a famous component LibreOffice's writer and clerk, but it's used in different areas. First, I would like to talk some things about base. So if you are not familiar with the component just I would like to let you know some details. There are two modules which are strongly related to the base module. The connectivity and the db access. The connectivity module is used for connecting to a database management system. Microsoft Access uses its own database management system, but LibreOffice base is used only with external databases. At least it's not in the core project. Also, there is a module called db access. It is representing the logic which is used for showing the UI itself and operating the database management system in the background. And what I would like to talk about is the improvements in that area. There are three main topics which I would like to talk about. The first one is the default database management system. There are two options when you want to connect to a database. You can either have external connection, that means that you can use a database server or you can use an embedded database. That means that you have the odb file. It's actually a zip file as you may already know. In the zip file itself, there is the data and the schema of the database. If you want to go for an embedded database, then you can choose either Firebird or HisQLDB. And that's one topic because we wanted to make Firebird the default and HisQLDB is absolute. The other topic is migration from HisQLDB to Firebird. That's needed because we turned HisQLDB as an absolute solution and it has a Java runtime environment as its dependency, which is a huge dependency in its own. And also the third topic is about my SQL connector. With LibreOffice, you can connect to my SQL and MariaDB not only with GDBC but with the native connector as well. First, I would like to talk about the connectivity module and the SDBC driver itself. It's the API which LibreOffice uses and it's very similar to the GDBC API. We have a driver which can create connections and with each connection we can create statements. For example, a query or insert statement and so on. And we can have for example with that X database metadata information about the database and all that can be received with the help of result set and it also has information which is contained by X result set metadata. So these are interfaces and there are several implementations of the driver for each database management system or for each connecting solution. For example we have ODBC and EDBC which X has as well. But LibreOffice has a native connectors. These are just examples. The three interesting example is the QLDB and the Firebird driver which I'm most concerned in and in my SQSC that's the native connector name of the implementation of the native connector and with QLDB and Firebird we can choose either to connect to a remote server or to an embedded server. Okay So comparing Firebird and QLDB as an embedded database that I found three reasons why we would go for Firebird. The most important is maintainability because QLDB is a Java-based database management system because of that we have to make a Java calls from C++ and that causes some trouble when we would like to debug the application and also another aspect is performance and the third is the state of the implementation itself that's the one we can change. So one of my works was about improving the Firebird driver like two years ago we made an upgrade to the 3.0 version which was kind of huge work because the architecture of the Firebird management system database management system changed and because of that we had to remake the make files related to this which can be a bit tricky. Also another was to allow auto-incremental values and saving the RF format of Firebird inside the ODB file with this method we achieved that the ODB file is portable which is kind of a requirement we have also creating relationships didn't work with the UI which is now working and there are a lot of more changes which had less impact but they were interesting as well. After upgrading the Firebird driver there is this need that we should get rid of the QLDB because of the Java dependency that's a tricky thing to do because one thing that is really needed from the users is to ensure that their files are usable in the future times as well so backward compatibility is really important because of that we created a migration assistant tool which has the task to move the database itself which is inside the ODB file to another format the Firebird format but problems that I faced during the migration creation of the migration tool is that the migration should be processed without the QLDB system itself so that uses Java environment because of that it cannot be used and that's the whole point of the migration so I had to look at the implementation of QLDB and also the Fireformat which was not documented every pieces of it also a big challenge was to understand the binary format in which the data is stored okay but the migration assistant tool is created and it works in almost every database that it's created of course there are problems which are dragged in the bugzilla one big program is that we also want to migrate the views and the views can be really complex considering that we have functions which are not compatible and which are not present in the SQS standard for example when we want to migrate QLDB to Firebird QLDB has the Concat function as a keyword for concatenating strings and the other hand Firebird has these two vertical lines to do that and that's just one example there are a lot of functions which are not in the standard and also that would be good if this tool would be able not only to migrate QLDB to Firebird but to migrate QLDB to everything that means the SDBC API or to move a step further it should be possible to move something to something of course it has a complexity and I would like to now turn to the third topic which is the minus QL connector so what we have here there are more ways to connect to MySQL or MariaDB database one is GDBC and there are three native ways there are the C API and the C++ API and the C API is implemented by MariaDB and MySQL part and the difference is the license while MySQL C++ connector cannot be used in the core project because it's GPL licensed but on the other hand MySQL the MariaDB C API could be used and because of that before the work we did the MySQL native connector was used as an extension so what? the problem with having the MySQL connector as an extension is that it needs further steps to install it it seems to be not a big problem but it annoys the user the user has to know that it exists and so but the biggest problem with that is maintainability because when it is an extension the driver itself then it wouldn't track the changes which we made on the core project and because of that it can happen that the extension cannot be used anymore also for example clang plugins wouldn't apply on the extension and any other static analysis tool and tests and so on ok so when I implemented the driver I used the new driver I used the MariaDB C API and in that way we could move the core stuff into the core project and there is an example function just for fun so you can see that it's a C API this function MySQL statement prepare is used for preparing prepare statement it gets three parameters statement handle which represents the statement itself and MySQL query ok and what I also have here is interesting concepts of the MySQL implementation one interesting thing at least for me it was the memory management because I get a bunch of pointers from the MySQL API but I don't have to free them there are separate functions for freeing the resources also an interesting thing for me an interesting thing was that there are two implementations for result set in the C API separate implementation for the statements and the prepared statements that's interesting because SDBC has only one typically that could be solved and another interesting concept is to how to move the cursor MySQL allows only to move the cursor of the result set forward but SDBC would allow to move it backward as well that can be done but it's performance problem because then you have to reopen the cursor and you can go wherever you want another thing that we accomplished is to test the functionality of the driver the problem here is that it's not an embedded database so we cannot do that automatically the one who wants to test this functionality has to have server MySQL server somewhere because of that the unit test which we made can be used only with explicitly saying it after the build so there is this manual execution and we can pass an environment variable which contains the URL for the database and the password and then the functionality can be tested and some other interesting problems I faced one is a parallel execution of more results it's not supported by the C API but supported by the SDBC so what I did is to store the result in memory with that it can be curated later that way I can free the minus QR resource and I can use it again another challenge was the ex database metadata implementation because the C++ API which was before had provided methods which was really similar to the which were really similar to the SDBC methods so there were nothing to do but with the C API these methods are not available so I had to use SQL queries the challenge with that is that it's not as strongly typed as C++ and the developing in that way is a bit tricky but the most of the methods now works and the third which I would like to mention is that three days from now I worked on a bug here in Brussels in the Hackfest and that's when we use the native MySQL API so the SDBC API which I implemented then when we open the relations tab this tab is used for creating relations which means foreign keys mostly so when we open it it turns out to be a bit slow that means on my machine MySQL server it takes about 7 seconds and why is that so slow one answer could be that also a bunch of system tables are shown in the tables menu there and that is maybe not so interesting because most of the users is not concerned about relations between system tables so my plan is to get rid of those system tables and only QRE the normal tables for the relationships menu okay so that was all I wanted to talk about I don't know if you have any questions yes testing base I don't know when did you come too late obviously okay about the migration about the migration part there is tracker page in bugzilla which contains links to all of those issues there are a lot which are solved and there are a lot which need further work on that I'm aware of them okay thank you