Change Details

The problem: ```frameworks/baloo/src/engine/idutils.h:106 inline quint64 statBufToId(const QT_STATBUF& stBuf) { // We're loosing 32 bits of info, so this could potentially break // on file systems with really large inode and device ids return devIdAndInodeToId(static_cast<quint32>(stBuf.st_dev), static_cast<quint32>(stBuf.st_ino)); } ``` This id is central and used to access info in several databases. An id of the backend db looks like this ``` typedef struct MDB_val { size_t mv_size; /**< size of the data item */ void *mv_data; /**< address of the data item */ } MDB_val; ``` and is used e.g. like this ``` MDB_val key; key.mv_size = sizeof(quint64); key.mv_data = static_cast<void*>(&docId); ``` This needs to change see T7860. Suggested approach: # Aliases: - `typedef quint64 DocId;` - `typedef quint32 Inode;` - `typedef quint32 DeviceId;` - replace `quint64` with `DocId` ~528 times - substitute quint32 with `Inode` or `DeviceId` - `#include idutils.h` where needed This diff will be huge, but easy to review These changes should be neutral. Are they really? # create create `class DocId` - 2 members: DeviceId and Inode - multiple constructors and operator implementations - Remove `typedef quint64 DocId;` This should still be neutral. Is it really? Does this change affect performance? # centralize reading and writing of ids in DocId class - Hopefully this will offer the oportunity to change e.g. Inode to 64bit and a better DeviceId while retaining compatibility to existing databases with 64bit DocIds. I have the feeling that is possible, but not idea how, yet. Theoretically `DocId`s with different sizes can coexist within a database. However, trouble comes with code like this: ``` MDB_val val; int rc = mdb_get(m_txn, m_dbi, &key, &val); QVector<quint64> list(val.mv_size / sizeof(quint64)); memcpy(list.data(), val.mv_data, val.mv_size); ``` Finally, in a distant future: - Change DocId creation to be really unique. There's a dilemma lurking here. Diffs should be small and digestable but the whole change should be atomic.

The problem: ```frameworks/baloo/src/engine/idutils.h:106 inline quint64 statBufToId(const QT_STATBUF& stBuf) { // We're loosing 32 bits of info, so this could potentially break // on file systems with really large inode and device ids return devIdAndInodeToId(static_cast<quint32>(stBuf.st_dev), static_cast<quint32>(stBuf.st_ino)); } ``` This id is central and used to access info in several databases. An id of the backend db looks like this ``` typedef struct MDB_val { size_t mv_size; /**< size of the data item */ void *mv_data; /**< address of the data item */ } MDB_val; ``` and is used e.g. like this ``` MDB_val key; key.mv_size = sizeof(quint64); key.mv_data = static_cast<void*>(&docId); ``` This needs to change see T7860. Suggested approach: # Aliases: - `using DocId = quint64;` - `typedef Inode = quint32;` - `typedef DeviceId = quint32;` - replace `quint64` with `DocId` ~528 times - substitute quint32 with `Inode` or `DeviceId` - `#include idutils.h` where needed This diff will be huge, but easy to review These changes should be neutral. Are they really? # create create `class DocId` - 2 members: DeviceId and Inode - multiple constructors and operator implementations - Remove `typedef quint64 DocId;` This should still be neutral. Is it really? Does this change affect performance? # centralize reading and writing of ids in DocId class - Hopefully this will offer the oportunity to change e.g. Inode to 64bit and a better DeviceId while retaining compatibility to existing databases with 64bit DocIds. I have the feeling that is possible, but not idea how, yet. Theoretically `DocId`s with different sizes can coexist within a database. However, trouble comes with code like this: ``` MDB_val val; int rc = mdb_get(m_txn, m_dbi, &key, &val); QVector<quint64> list(val.mv_size / sizeof(quint64)); memcpy(list.data(), val.mv_data, val.mv_size); ``` Finally, in a distant future: - Change DocId creation to be really unique. There's a dilemma lurking here. Diffs should be small and digestable but the whole change should be atomic.

The problem: ```frameworks/baloo/src/engine/idutils.h:106 inline quint64 statBufToId(const QT_STATBUF& stBuf) { // We're loosing 32 bits of info, so this could potentially break // on file systems with really large inode and device ids return devIdAndInodeToId(static_cast<quint32>(stBuf.st_dev), static_cast<quint32>(stBuf.st_ino)); } ``` This id is central and used to access info in several databases. An id of the backend db looks like this ``` typedef struct MDB_val { size_t mv_size; /**< size of the data item */ void *mv_data; /**< address of the data item */ } MDB_val; ``` and is used e.g. like this ``` MDB_val key; key.mv_size = sizeof(quint64); key.mv_data = static_cast<void*>(&docId); ``` This needs to change see T7860. Suggested approach: # Aliases: - `typedef- `using DocId = quint64 DocId;;` - `typedef quint32 Inode;Inode = quint32;` - `typedef quint32 DeviceId;DeviceId = quint32;` - replace `quint64` with `DocId` ~528 times - substitute quint32 with `Inode` or `DeviceId` - `#include idutils.h` where needed This diff will be huge, but easy to review These changes should be neutral. Are they really? # create create `class DocId` - 2 members: DeviceId and Inode - multiple constructors and operator implementations - Remove `typedef quint64 DocId;` This should still be neutral. Is it really? Does this change affect performance? # centralize reading and writing of ids in DocId class - Hopefully this will offer the oportunity to change e.g. Inode to 64bit and a better DeviceId while retaining compatibility to existing databases with 64bit DocIds. I have the feeling that is possible, but not idea how, yet. Theoretically `DocId`s with different sizes can coexist within a database. However, trouble comes with code like this: ``` MDB_val val; int rc = mdb_get(m_txn, m_dbi, &key, &val); QVector<quint64> list(val.mv_size / sizeof(quint64)); memcpy(list.data(), val.mv_data, val.mv_size); ``` Finally, in a distant future: - Change DocId creation to be really unique. There's a dilemma lurking here. Diffs should be small and digestable but the whole change should be atomic.