laskoviymishka opened a new issue, #2083:
URL: https://github.com/apache/iceberg-go/issues/2083

   ## Summary
   
   As part of the v1.0.0 API-freeze preparation (umbrella #2062), relocate the 
table "services/actions" that today hang off `table.Table` but are not part of 
the core read/write/commit contract into their own subpackages. This is a 
bounded, deliberate slice, distinct from the full table-package decomposition 
in #1149 (which stays post-v1): it moves only the genuinely separable, 
self-contained services.
   
   Because it relocates exported methods, it is breaking and therefore belongs 
in the pre-v1 window.
   
   ## Motivation
   
   `table.Table` has accreted surface that is conceptually separate from 
loading, scanning, and committing a table: filesystem maintenance (orphan-file 
cleanup / "vacuum"), read-only metadata inspection ("metadata tables"), and 
rewrite/compaction actions. Other clients keep these apart: the Java 
implementation exposes them as `Actions`, and PyIceberg exposes inspection as a 
`table.inspect` metadata-tables API. Aligning the Go surface pre-v1 keeps the 
core `Table` focused and gives these services a home that a later module split 
can build on.
   
   Honest scope note: the primary wins here are API clarity, cross-client shape 
parity, and cleaner package seams. This is not, on its own, a large 
binary-footprint reduction, because the scan and write paths keep the Arrow 
dependency regardless of where these services live.
   
   ## Proposed slices (decomposable across independent PRs)
   
   ### Slice 1 — orphan cleanup / vacuum (cleanest seam)
   
   Move the orphan-cleanup surface off `Table` into a new maintenance package. 
It is a filesystem walk plus delete with no commit machinery, so it is the most 
self-contained piece.
   
   Symbols: `Table.DeleteOrphanFiles`, `Table.PlanOrphanFiles`, 
`Table.ExecuteOrphanCleanup`, `Table.PurgeFiles`, and the supporting 
`OrphanCleanupOption`, `WithDeleteFunc`, `WithFilesOlderThan`, `WithDryRun`, 
`WithMaxConcurrency`, `PrefixMismatchMode`, `OrphanCleanupResult`, 
`OrphanCleanupPlan`.
   
   This move is also the natural moment to drop the deprecated 
`WitMaxConcurrency` typo alias (see the deprecation sweep in #2062).
   
   ### Slice 2 — inspect / metadata tables
   
   Move the metadata-inspection surface into a new inspect package. It is 
read-only and self-contained, producing Arrow record readers, and is the 
largest clean cluster.
   
   Symbols: `Table.Inspect` and `InspectTable` with `History`, `Snapshots`, 
`Manifests`, `Refs`, `MetadataLogEntries`, `Entries`, `Files`, `Partitions`, 
`DeleteFiles`, plus `InspectOption` / `WithInspectAllocator`.
   
   ### Slice 3 — rewrite / compaction actions (optional, may defer)
   
   `Transaction.RewriteDataFiles` and `Transaction.RewriteManifests` are more 
entangled: they live on `Transaction`, drive the commit machinery, and already 
lean on the existing `table/compaction` subpackage. Lower priority; can be 
sequenced last or left in place.
   
   ## Open design decision
   
   How the relocated services take the table:
   
   - free functions, e.g. `maintenance.DeleteOrphanFiles(ctx, tbl, opts...)`; or
   - a small facade, e.g. `maintenance.For(tbl).DeleteOrphanFiles(ctx, 
opts...)` and `inspect.New(tbl)`.
   
   The facade reads more discoverably and is closer to the Java `Actions` 
factory shape; free functions are simpler. Worth settling before slice 1 lands 
so the two slices are consistent.
   
   ## Non-goals
   
   - The full `table` decomposition (#1149) stays post-v1.
   - The Arrow-coupled scan and write paths remain in `table`.
   
   ## Sequencing
   
   Slice 1 (vacuum) then slice 2 (inspect), each an independent breaking PR, 
leaving `Table` as the entry point for core read/write/commit only. Slice 3 
optional/last.
   
   Part of #2062.
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to