zeroshade commented on code in PR #177:
URL: https://github.com/apache/iceberg-go/pull/177#discussion_r1813481928
##########
manifest.go:
##########
@@ -831,14 +946,53 @@ func (m *manifestEntryV1) FileSequenceNum() *int64 {
return m.FileSeqNum
}
-func (m *manifestEntryV1) DataFile() DataFile { return &m.Data }
+func (m *manifestEntryV1) DataFile() DataFile { return m.Data }
+
+// ManifestEntryV2Builder is a helper for building a V2 manifest entry
+// struct which will conform to the ManifestEntry interface.
+type ManifestEntryV2Builder struct {
+ m *manifestEntryV2
+}
+
+// NewManifestEntryV2Builder is passed all of the required fields and then
allows
+// all of the optional fields to be set by calling the corresponding methods
+// before calling [ManifestEntryV2Builder.Build] to construct the object.
+func NewManifestEntryV2Builder(status ManifestEntryStatus, snapshotID int64,
data DataFile) *ManifestEntryV2Builder {
+ return &ManifestEntryV2Builder{
+ m: &manifestEntryV2{
+ EntryStatus: status,
+ Snapshot: &snapshotID,
+ Data: data,
Review Comment:
That's a good point. Though since we're using a `*dataFile` we're avoiding
copying right? We're just copying the pointer.
For the second point, that's a better point which might make it worthwhile
to keep things as is then. The primary reason for using an interface was so
that we're not exposing the underlying members except via getters which all
have to be public in order to allow the avro decoding to work. Given this, I
think we should just keep it as is using the interface type directly then.
--
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: issues-unsubscr...@iceberg.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@iceberg.apache.org
For additional commands, e-mail: issues-h...@iceberg.apache.org
