You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@iotdb.apache.org by Giorgio Zoppi <gi...@gmail.com> on 2020/05/26 14:05:47 UTC
Serialization discussion
Hello Gents,
i would like to open discussion about the method serializeTo in *Headers
and so on since i use the Java counterpart for the serialization.
Those violate the *interface*-*segregation principle* (ISP) that states
that no client should be forced to depend on methods it does not use,
i would propose to separate serializeTo to an external interface and
implement that interface. So it will make easy for testing, testing just
a single concern. Let me know what you think about.
BR,
Giorgio
Re: Serialization discussion
Posted by Jialin Qiao <qj...@mails.tsinghua.edu.cn>.
Hi Giorgio,
Thank you, I will have a look.
Best,
--
Jialin Qiao
School of Software, Tsinghua University
乔嘉林
清华大学 软件学院
> -----原始邮件-----
> 发件人: "Giorgio Zoppi" <gi...@gmail.com>
> 发送时间: 2020-05-31 04:06:01 (星期日)
> 收件人: dev@iotdb.apache.org
> 抄送:
> 主题: Re: Serialization discussion
>
> Hello Gents,
>
> Ok I came up with this design:
>
> package org.apache.iotdb.tsfile.common.serialization;
> import java.io.IOException;
> import java.io.InputStream;
> import java.io.OutputStream;
> import java.nio.ByteBuffer;
>
> public interface IDataSerializer<T, V> {
> int serializeTo(T data, OutputStream outputStream) throws IOException;
> int serializeTo(T data, ByteBuffer buffer);
> T deserializeFrom(ByteBuffer buffer, V options);
> T deserializeFrom(InputStream inputStream, V options);
> }
>
>
> And i have for example, something like this:
> public class PageHeaderSerializer implements IDataSerializer<PageHeader,
> TSDataType> {
>
> @Override
> public int serializeTo(PageHeader data, OutputStream outputStream) throws
> IOException {
> // code
> }
> @Override
> public int serializeTo(PageHeader data, ByteBuffer buffer) {
> /// snip.
> }
>
> @Override
> public PageHeader deserializeFrom(ByteBuffer buffer, TSDataType options) {
> ///
> }
>
> @Override
> public PageHeader deserializeFrom(InputStream inputStream, TSDataType
> options) {
> // snippet
> }
> }
> In this way we have a class that has the respobility of serialization. We
> delegate the serialization to an appropriate class without breaking the
> interface.
> This is the first step.
>
> BR,
> Giorgio
Re: Serialization discussion
Posted by Giorgio Zoppi <gi...@gmail.com>.
Hello Gents,
Ok I came up with this design:
package org.apache.iotdb.tsfile.common.serialization;
import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;
import java.nio.ByteBuffer;
public interface IDataSerializer<T, V> {
int serializeTo(T data, OutputStream outputStream) throws IOException;
int serializeTo(T data, ByteBuffer buffer);
T deserializeFrom(ByteBuffer buffer, V options);
T deserializeFrom(InputStream inputStream, V options);
}
And i have for example, something like this:
public class PageHeaderSerializer implements IDataSerializer<PageHeader,
TSDataType> {
@Override
public int serializeTo(PageHeader data, OutputStream outputStream) throws
IOException {
// code
}
@Override
public int serializeTo(PageHeader data, ByteBuffer buffer) {
/// snip.
}
@Override
public PageHeader deserializeFrom(ByteBuffer buffer, TSDataType options) {
///
}
@Override
public PageHeader deserializeFrom(InputStream inputStream, TSDataType
options) {
// snippet
}
}
In this way we have a class that has the respobility of serialization. We
delegate the serialization to an appropriate class without breaking the
interface.
This is the first step.
BR,
Giorgio
Re: Serialization discussion
Posted by Giorgio Zoppi <gi...@gmail.com>.
On 5/27/20 8:51 AM, Jialin Qiao wrote:
> Hi,
>
> Providing a Serializable interface looks more uniform.
> However, if more and more classes implement this interface, it may be hard for developers to find usage of a specific class, such as PageHeader.serialize or ChunkHeader.serialize. This may be a problem...
This is interesting point, that triggered me my curiosity, instead of
depending on hierarchy we could get rid of serialization code from
classes. The final result could be:
*try (var stream = new FileOutputStream("pageheader.dat"))* {
var serializer = new PageHeaderSerializer();
serializer.serializeTo(stream);
}
All serializer objects will implement serializeTo and deserializeTo, so in this case we can enforce the separation of concern. The data/model header is just a stupid bean without any logic, where each serializer implements
the DataSerializerInterface.
Best Regards,
Giorgio.
Re: Serialization discussion
Posted by Jialin Qiao <qj...@mails.tsinghua.edu.cn>.
Hi,
Providing a Serializable interface looks more uniform.
However, if more and more classes implement this interface, it may be hard for developers to find usage of a specific class, such as PageHeader.serialize or ChunkHeader.serialize. This may be a problem...
Thanks,
--
Jialin Qiao
School of Software, Tsinghua University
乔嘉林
清华大学 软件学院
> -----原始邮件-----
> 发件人: "Xiangdong Huang" <sa...@gmail.com>
> 发送时间: 2020-05-27 08:37:25 (星期三)
> 收件人: dev@iotdb.apache.org
> 抄送:
> 主题: Re: Serialization discussion
>
> Hi Giorgio,
>
> I think it is ok to abstract the two methods as an interface.
> But what do you think about the deserializeFrom() method?
>
> > since we use our free time and weekends.
> Many thanks for your effort :D
>
> Best,
> -----------------------------------
> Xiangdong Huang
> School of Software, Tsinghua University
>
> 黄向东
> 清华大学 软件学院
>
>
> Giorgio Zoppi <gi...@gmail.com> 于2020年5月27日周三 上午5:20写道：
>
> >
> > On 5/26/20 4:46 PM, Xiangdong Huang wrote:
> > > Hi Giorgio,
> > >
> > > Welcome to discuss the class/interface design.
> > > I believe there must be a lot of class/interface design we can improve in
> > > the current implementation.
> > >
> > > Are you talking about the PageHeader and ChunkHeader?
> > > IMO, they are considered as JavaBeans, and serialization/deserialization
> > > methods are needed (if we do not use java.io.Serializable)
> >
> > Yes, but suggest to create an appropriate interface, because if i need
> > to test only those, i can mock. Example.
> >
> > public interface DataSerializable {
> >
> > void serializeTo(OutputStream stream) throws SerializationException;
> >
> > void serializeTo(ByteBuffer buffer) throws SerializationException;
> >
> > }
> >
> > public class PageHeader implements DataSerializable {
> >
> > }
> >
> > So you can treat a PageHeader, ChunkHeader as the think and create
> > composition
> >
> > while deserializing. This will our development for us because we can
> > just implement DataSerializable and mock
> >
> > whatever we want without importing the real implementation.
> >
> > This is my point, if the community agrees i can provide a PR. We are
> > slowly progressing with the native but still a lot of time is needed
> >
> > since we use our free time and weekends.
> >
> > Best Regards,
> >
> > Giorgio.
> >
> >
> >
> >
Re: Serialization discussion
Posted by Xiangdong Huang <sa...@gmail.com>.
Hi Giorgio,
I think it is ok to abstract the two methods as an interface.
But what do you think about the deserializeFrom() method?
> since we use our free time and weekends.
Many thanks for your effort :D
Best,
-----------------------------------
Xiangdong Huang
School of Software, Tsinghua University
黄向东
清华大学 软件学院
Giorgio Zoppi <gi...@gmail.com> 于2020年5月27日周三 上午5:20写道：
>
> On 5/26/20 4:46 PM, Xiangdong Huang wrote:
> > Hi Giorgio,
> >
> > Welcome to discuss the class/interface design.
> > I believe there must be a lot of class/interface design we can improve in
> > the current implementation.
> >
> > Are you talking about the PageHeader and ChunkHeader?
> > IMO, they are considered as JavaBeans, and serialization/deserialization
> > methods are needed (if we do not use java.io.Serializable)
>
> Yes, but suggest to create an appropriate interface, because if i need
> to test only those, i can mock. Example.
>
> public interface DataSerializable {
>
> void serializeTo(OutputStream stream) throws SerializationException;
>
> void serializeTo(ByteBuffer buffer) throws SerializationException;
>
> }
>
> public class PageHeader implements DataSerializable {
>
> }
>
> So you can treat a PageHeader, ChunkHeader as the think and create
> composition
>
> while deserializing. This will our development for us because we can
> just implement DataSerializable and mock
>
> whatever we want without importing the real implementation.
>
> This is my point, if the community agrees i can provide a PR. We are
> slowly progressing with the native but still a lot of time is needed
>
> since we use our free time and weekends.
>
> Best Regards,
>
> Giorgio.
>
>
>
>
Re: Serialization discussion
Posted by Giorgio Zoppi <gi...@gmail.com>.
On 5/26/20 4:46 PM, Xiangdong Huang wrote:
> Hi Giorgio,
>
> Welcome to discuss the class/interface design.
> I believe there must be a lot of class/interface design we can improve in
> the current implementation.
>
> Are you talking about the PageHeader and ChunkHeader?
> IMO, they are considered as JavaBeans, and serialization/deserialization
> methods are needed (if we do not use java.io.Serializable)
Yes, but suggest to create an appropriate interface, because if i need
to test only those, i can mock. Example.
public interface DataSerializable {
void serializeTo(OutputStream stream) throws SerializationException;
void serializeTo(ByteBuffer buffer) throws SerializationException;
}
public class PageHeader implements DataSerializable {
}
So you can treat a PageHeader, ChunkHeader as the think and create
composition
while deserializing. This will our development for us because we can
just implement DataSerializable and mock
whatever we want without importing the real implementation.
This is my point, if the community agrees i can provide a PR. We are
slowly progressing with the native but still a lot of time is needed
since we use our free time and weekends.
Best Regards,
Giorgio.
Re: Serialization discussion
Posted by Xiangdong Huang <sa...@gmail.com>.
Hi Giorgio,
Welcome to discuss the class/interface design.
I believe there must be a lot of class/interface design we can improve in
the current implementation.
Are you talking about the PageHeader and ChunkHeader?
IMO, they are considered as JavaBeans, and serialization/deserialization
methods are needed (if we do not use java.io.Serializable)
But indeed serializeTo(outputStream) and serializeTo(ByteBuffer) are
alternative.
What do you think?
Best,
-----------------------------------
Xiangdong Huang
School of Software, Tsinghua University
黄向东
清华大学 软件学院
Giorgio Zoppi <gi...@gmail.com> 于2020年5月26日周二 下午10:06写道：
> Hello Gents,
>
> i would like to open discussion about the method serializeTo in *Headers
> and so on since i use the Java counterpart for the serialization.
>
> Those violate the *interface*-*segregation principle* (ISP) that states
> that no client should be forced to depend on methods it does not use,
>
> i would propose to separate serializeTo to an external interface and
> implement that interface. So it will make easy for testing, testing just
>
> a single concern. Let me know what you think about.
>
> BR,
>
> Giorgio
>
>
>
>