>From Ali Alsuliman <[email protected]>: Ali Alsuliman has uploaded a new patch set (#2). ( https://asterix-gerrit.ics.uci.edu/c/asterixdb/+/21676?usp=email )
Change subject: [ASTERIXDB-3817][STO] Extract VTree page mutation into a collaborator ...................................................................... [ASTERIXDB-3817][STO] Extract VTree page mutation into a collaborator VTree carried tree navigation, page-level insert/split/delete, directory-chain maintenance, static-structure attachment and its accessor in one 1411-line class. Move the page-mutation half into VTreePageMutator: 871 lines remain in VTree, 657 are in the new class. The move is verbatim. The extracted code reaches exactly five pieces of VTree state -- the buffer cache, file id, page manager, directory frame factory, and whether the tuple layout is quantized -- and nothing about centroids, distance metrics, cross-pollination or the static structure. So the seam is just the two entry points insertIntoDataPages and tryPhysicalDelete, both of which already took the directory page id the caller had resolved. Token streams before and after are identical; the only textual differences are three formatter line wraps, caused by getFileId() becoming a supplier call and one signature losing `private`. The file id is an IntSupplier rather than an int because it is assigned at activation and changes across an activate/deactivate cycle, so it cannot be captured in the VTree constructor. The entry points are package-private, which leaves the module's API surface unchanged while keeping the class testable. Also make out-of-order use of the static-structure navigation state loud. That group is populated only between setStaticStructure() and resetInitialization(), and a read outside the window silently yielded null for the page map and 0 for both centroid counts -- which the flush path turns into a NullPointerException several frames away or, worse, a silent "no centroids to copy". The three getters now report the actual cause. setRootPageId is documented as independent of that pair: the bulk loaders and LSMVTreeDiskComponent call it in either order relative to attachment. No behaviour change. The 31 LSM VTree tests pass, and the new attach check does not trip in any of them. Ext-ref: MB-73194 Co-Authored-By: Claude Opus 5 <[email protected]> Change-Id: I679d52d9bc75b345fe2cec61e863c422c40a3e2a --- M hyracks-fullstack/hyracks/hyracks-storage-am-vtree/src/main/java/org/apache/hyracks/storage/am/vector/impls/VTree.java A hyracks-fullstack/hyracks/hyracks-storage-am-vtree/src/main/java/org/apache/hyracks/storage/am/vector/impls/VTreePageMutator.java 2 files changed, 703 insertions(+), 586 deletions(-) git pull ssh://asterix-gerrit.ics.uci.edu:29418/asterixdb refs/changes/76/21676/2 -- To view, visit https://asterix-gerrit.ics.uci.edu/c/asterixdb/+/21676?usp=email To unsubscribe, or for help writing mail filters, visit https://asterix-gerrit.ics.uci.edu/settings?usp=email Gerrit-MessageType: newpatchset Gerrit-Project: asterixdb Gerrit-Branch: master Gerrit-Change-Id: I679d52d9bc75b345fe2cec61e863c422c40a3e2a Gerrit-Change-Number: 21676 Gerrit-PatchSet: 2 Gerrit-Owner: Ali Alsuliman <[email protected]> Gerrit-CC: Anon. E. Moose #1000171
