Conversation
- the forward of size to the iterator in SoilIndex is overridden in both subclasses to read from headerpage, do that here - The size in SoilIndexIterator should not be the slow one, as this is very confusing when we fall bacl to the slow case. It is overridden in all subclasses. Use index size here - add esxplizit #sizeViaIteration - Move size that accesses readVersion to SoilRestoringIndexIterator This still has the problem that the #size is different if called via the index vs. the iterator. A next refactoring could change it to *always* forward to the iterator from the index, as we do with many other methods
| the header page is newer than the current transaction we need to scan | ||
| the index for the size" | ||
| headerPage := index headerPage. | ||
| ^ (readVersion isNil or: [ headerPage lastTransaction > readVersion ]) |
There was a problem hiding this comment.
I'm not sure we should fall back to the scanning one. Especially here no readVersion always scans. And in transactions we want the size for that readVersion and scanning always gives the actual size. Well at least if we are not restoring all pages which would be super slow
There was a problem hiding this comment.
so should we always read the size from the header (like "index size" already does?)
There was a problem hiding this comment.
That would be my first guess. If the header page is copied it will have the bettwr number, no?
There was a problem hiding this comment.
I commited a version where #size is just index size, but now size and #isEmpty do not agree (see failing test)
There was a problem hiding this comment.
Maybe a good one as we know that the size in the header page can deviate from the actual item count
… #isEmpty (see failing test)
2 participants
This still has the problem that the #size is different if called via the index vs. the iterator. A next refactoring could change it to always forward to the iterator from the index, as we do with many other methods