Marcus Denker

Documentation should be edited here: https://github.com/ApptiveGrid/Soil/tree/main/docs

this was done

Btree remove just removes the key from the data page, \ we have to check if we need to recursively update the index pages, too

The same problem means that *changes* are ingored, too. Nothing should prevent us tx1 to change the value (locally). ``` "We should be able to change it locally here" tx1...

We have already a skipped test that fails due to the same reason I think: SoilIndexedDictionaryTest>>#testRemoveKeyWithTwoTransactions ``` "but removeKey: does not see it, we can remove it without error" tx...

a halt in SoilIndexIterator>>#historicValueAt:ifAbsent: is the best place to check what happens -> when a value is removed, it has ID 0:0 -> we try to restore it Now if...

#size for now is implemented by a linear scan: ``` size "We iterate over all elements to get the size. Slow!" ^ self newIterator size ``` This is very slow...

"in order" means which order? The OrderedDictionary is sorted by when the key was added, not in the order that they are later in the index (see https://github.com/ApptiveGrid/Soil/issues/415 )

with remove and add being in two different dictionaries, there is no order between them: we log first all adds, then all removes. This can lead to the order between...

Now SoilIndexedDictionary uses newValues removedValues just for creating the journal. To have the Journal in correct oder, we need to instead have one OrdredCollection that stores both add and removes....