liurenjie1024 commented on code in PR #82:
URL: https://github.com/apache/iceberg-rust/pull/82#discussion_r1364825386


##########
crates/iceberg/src/spec/values.rs:
##########
@@ -996,10 +1008,552 @@ mod timestamptz {
     }
 }
 
+mod serde {
+    use std::collections::BTreeMap;
+
+    use crate::{
+        spec::{PrimitiveType, Type},
+        Error, ErrorKind,
+    };
+
+    use super::{Literal, PrimitiveLiteral};
+    use serde::{
+        de::Visitor,
+        ser::{SerializeMap, SerializeSeq, SerializeStruct},
+        Deserialize, Serialize,
+    };
+    use serde_bytes::ByteBuf;
+    use serde_derive::Deserialize as DeserializeDerive;
+    use serde_derive::Serialize as SerializeDerive;
+
+    #[derive(SerializeDerive, DeserializeDerive)]
+    #[serde(transparent)]
+    /// Raw literal representation used for serde. The serialize way is used 
for Avro serializer.
+    pub struct RawLiteral(RawLiteralEnum);
+
+    impl RawLiteral {
+        /// Covert literal to raw literal.
+        pub fn try_from(literal: Literal, ty: &Type) -> Result<Self, Error> {
+            Ok(Self(RawLiteralEnum::try_from(literal, ty)?))
+        }
+
+        /// Convert raw literal to literal.
+        pub fn try_into(self, ty: &Type) -> Result<Option<Literal>, Error> {
+            self.0.try_into(ty)
+        }
+    }
+
+    #[derive(SerializeDerive, Clone)]
+    #[serde(untagged)]
+    enum RawLiteralEnum {
+        Null,
+        Boolean(bool),
+        Int(i32),
+        Long(i64),
+        Float(f32),
+        Double(f64),
+        String(String),
+        Bytes(ByteBuf),
+        List(List),
+        StringMap(StringMap),
+        Record(Record),
+    }
+
+    #[derive(Clone)]
+    struct Record {
+        required: Vec<(String, RawLiteralEnum)>,
+        optional: Vec<(String, Option<RawLiteralEnum>)>,

Review Comment:
   I still don't get the point here. Is there a distinction for serializer when 
they implementing `serialize_i32(Some(1))` or `serialize_i32(1)`?



-- 
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

Reply via email to