List view
- No due date•138/139 issues closed
- No due date•1/2 issues closed
Instead of having an asynchronous `insert`, `delete`, `get` and `indexOf`, treat leaf pages as arrays of records, read leaf pages entirely like key pages.
No due date•4/5 issues closedBenchmarks and profiling.
No due date•7/7 issues closedInsert and delete operations.
No due date•10/11 issues closedLog the dirtying of leaf pages. Drive balancing from a balance log.
No due date•13/14 issues closedOngoing maintenance and other enlightenment from implementation. Maybe this issue is the application of enlightenment.
No due date•54/54 issues closedInstead of putting the Strata object into an unstable state, or flipping a switch that would mean that no operations are honored, restore the state so that the Strata object can continue serve requests that are unaffected by the error condition.
No due date•44/45 issues closedCounted b-trees are going to be implemented not internally, but using a well-documented recipe, just like null keys or duplicate keys. The same strategy for counting could be used for a Merkle tree, once there is an externalized balance interface that will allow the user to mirror a tree structure.
No due date•1/2 issues closedNeed to at times vacuum pages that have not been split or merged. Constant inserts and deletes to a leaf page can cause the leaf page log to grow and shrink without ever crossing the merge or split boundaries. The pages need to be identified and vacuumed. It might be as simple as comparing their record count to their log entry count and having a ratio that is the too-dirty ratio.
No due date•1/2 issues closedCreate a general purpose procedure for recovery. Create an object to co-ordinate that recovery, I believe. Recovery will not be magic. The user is going to have to be aware of the need for recovery and control the recovery through the recover interface which will probably be an object named `Medic`.
No due date•1/2 issues closedCreate a function that will iterate the tree read-only, checking the integrity of the tree page by page. It will not take priority over insert and delete operations.
No due date•0/2 issues closedExternalize the balance operation so that users can implement their own balance and partitioning strategies. There needs to be a method to get the dirty tree from which a plan can be build. Otherwise, there can be an explicit plan so that a tree can be mirrored. Ghost busting, splitting and merging are now invoked externally.
No due date•13/14 issues closedBalance operations can get out of the way of reads and writes quickly by first logging their changes using an exclusive lock, then rewriting altered pages leisurely, first using a shared lock to do an initial rewrite, then an exclusive lock to write any missed changes, and to move the new pages into place.
No due date•2/2 issues closedDelay the writing or flushing of writes to leaf and branch pages so that multiple writes to a single page are flushed to disk together and followed by a footer.
No due date•24/24 issues closedProvide the functionality necessary to implement reverse iteration, needed for Locket, but desired generally. Anything else that is on the front burner because of Locket, but not large enough to warrant it's own milestone should be attached to this milestone.
No due date•23/23 issues closedCreate a binary file format to store binary records and keys. This is a last call (not really) for changes to the JSON file format, so anything that you hoped to write out into the branch or leaf pages files should get written out now, even if there are no plans to use the information for the foreseeable future. The binary format will allow for the storage of `Buffer`, initially. `ArrayBuffer` can come later if it comes at all.
No due date•46/46 issues closedI've extracted both my caching and locking strategies into external libraries. I'd like to replaced the embedded logic with those external libraries, so that they can get some exercise. Caching needs to be external, since the new library has a new concept of a common cache, with instances for separate collections. That does not yet exist in the embedded logic. The locking strategy should be employed because it is versatile and I can see where it could be used to replace ad hoc concurrency control; a latch build using the external library could replace the countdowns seen here and there.
No due date•16/16 issues closedStore keys in branches because the key only changes at the time of balance. We can rewrite the branch page at balance time. A long time ago, balancing was triggered by inserts and deletes. Looking up keys was a way of saving ourselves writes that would block all other descents. Eventually I realized that splitting the moment a page is a candidate for split, as part of a descent was a false economy that made the b-tree wildly complex given concurrency. Then, years later, I realized that I'd not stored keys in branch pages for reasons that were no longer valid. Now, before I implement a binary file format, I want to implement this one major change to the tree architecture.
No due date•39/39 issues closed