Caolán McNamara
072c7b226b
db_maxkeys came from the index header, the key count of a page came from the
page itself, and node access used neither. Now the header value is capped to
the number of keys a DINDEX_PAGE_SIZE page can hold for the given key length,
each page keeps its own capacity and caps its key count to it, and node
positions are clamped to the same bound, so all three agree.
ODbaseIndex::CreateImpl worked out db_maxkeys from a four byte page header
while the reader counts eight bytes of page header, so use eight here too and
write an index the reader agrees with.
ONDXPage::Remove asserted on a position past the key count and then carried on
regardless, so return early instead.
ONDXPage::Merge added the key counts of two pages together in a sal_uInt16, so
widen the sum to sal_uInt32.
nValue was a file-level static shared by the page read and write operators for
no reason, so make it a local in the reader and write rPage.nCount directly.
The two GetChild overloads would load a child page that is already on the chain
of parents the descent came down, so leave such a page unread rather than
descending into a page we are inside. ONDXPage::Merge and ONDXPage::PrintPage
can then be handed a page that was left unread, so both check for one with
nothing loaded.
Signed-off-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Change-Id: Id51bf8368099447df41aaacbaebba7783c5769e2
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/9518
Reviewed-by: Noel Grandin <noel.grandin@collabora.com>
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
(cherry picked from commit db92d0be756305ec0b1e122a1d00333477c17ba5)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/209449
Tested-by: Xisco Fauli <xiscofauli@libreoffice.org>
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/209470
Tested-by: Jenkins
(cherry picked from commit 78cb164778)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/209479
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
Tested-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
Database Connectivity
Contains database pieces, drivers, etc.
dbaccess builds UI on top of this.
Testing
PostgreSQL
For testing, use:
podman pull postgres:latest
podman run --name=postgres -e POSTGRES_PASSWORD=foobarbaz -p 127.0.0.1:5432:5432 postgres:latest
In Base, Connect to an existing database, select PostgreSQL:
URL: host=127.0.0.1 port=5432 dbname=postgres
User: postgres
Password: foobarbaz
podman stop postgres
podman rm postgres
In order to test SCRAM authentication, create the container like this:
podman run --name=postgres -e POSTGRES_PASSWORD=foobarbaz -e POSTGRES_INITDB_ARGS=--auth-host=scram-sha-256 -e POSTGRES_HOST_AUTH_METHOD=scram-sha-256 -p 127.0.0.1:5432:5432 postgres:latest
MySQL
For mysql_test:
-
The CppunitTest_mysql_test unit test can be used to test the mysqlc library with any versions of mysql or mariadb server of your choice.
-
This test does not run automatically. It can be triggered with setting the environment variable "CONNECTIVITY_TEST_MYSQL_DRIVER".
-
The environment variable should contain a URL of the following format:
[user]/[passwd]@sdbc:mysql:mysqlc:[host]:[port]/db_name -
tl;dr:
podman pull mariadb/server
podman run --name=mariadb -e MYSQL_ROOT_PASSWORD=foobarbaz -p 127.0.0.1:3306:3306 mariadb/server
podman exec -it mariadb /bin/bash -c "echo -e CREATE DATABASE test | /usr/bin/mysql -u root"
(cd connectivity && make -srj8 CppunitTest_connectivity_mysql_test CONNECTIVITY_TEST_MYSQL_DRIVER="root/foobarbaz@sdbc:mysql:mysqlc:127.0.0.1:3306/test")
podman stop mariadb
podman rm mariadb
Firebird
Firebird has two primary file types:
-
Databases - FDB files. These are version-specific, platform-specific, optimized for performance, and thus incompatible between versions. These are what those comments are about. Initially, when FB integration was considered, these files were evaluated for ODBs, but were rejected because of the said incompatibility - even when the version is the same, it will differ on big endian architecture and little endian one. The problem discussed in those comments is when people open stand-alone FDBs that are shipped e.g. with FB installation itself, not when people open ODBs.
-
Database backups - FBKs. These are what we use inside ODBs. These are designed to be compatible, independent of architecture; and later versions of FB are always able to open FBKs created in older FB versions.
Our embedded FB is used like this:
- FBK is extracted from ODB;
- Embedded FB extracts the compatible FBK into an incompatible FDB (specific to this version of embedded FB DLL);
- FB works with this temporary FDB;
- When saving ODB, embedded FB backups the FDB into FBK again, and that is stored inside the ODB.
It, indeed, creates additional performance penalty, but makes the ODB readable by all the future LO versions, no matter what future FB version they embed.