Skip to content

Reorg introduce api package containing Entry interface#401

Open
steiler wants to merge 11 commits intomainfrom
reorgIntroduceAPI
Open

Reorg introduce api package containing Entry interface#401
steiler wants to merge 11 commits intomainfrom
reorgIntroduceAPI

Conversation

@steiler
Copy link
Collaborator

@steiler steiler commented Feb 19, 2026

Reorganizes the tree package by introducing a new pkg/tree/api surface and a pkg/tree/consts package, then updates the codebase to use those exported interfaces, types, and constants.

  • Adds a dedicated API layer (pkg/tree/api) with Entry, LeafVariants, delete-path types, and non-revertive tracking; introduces pkg/tree/ops helpers (e.g., GetByOwner) and an ops interface.
  • Moves tree constants to pkg/tree/consts and replaces many direct tree.RunningIntentName/RunningValuesPrio/Replace* usages with consts equivalents across datastore, targets, server, and tests.
  • Refactors core tree implementation to use the new API types: method visibility changes (e.g., ShouldDelete, GetOrCreateChilds, ToJsonInternal), LeafVariants accessors, and TreeContext now exposing SchemaClient, ExplicitDeletes, and NonRevertiveInfo.
  • Updates mocks and generated code to reflect new API package paths and added interface methods; adds a new mock for SdcpbPath.
  • Adjusts update/path handling with SdcpbPath() and updates callers, plus broad test updates to match new APIs and constants.

@steiler steiler requested a review from a team as a code owner February 19, 2026 14:24
@codecov
Copy link

codecov bot commented Mar 5, 2026

Copy link
Contributor

@faebr faebr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I really like the interface separation from the stateless ops. I always struggled to fully understand sharedEntryAttributes and this breaks it down! I assume the commented out functions in entry.go are the ones you will still implement right?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should the leaf_variants also be parts of the api / interface package or would it make sense to take this implementation into another package so to only have the interface definitions in the api package?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants