Good. I will look at it. Best, Taewoo
On Fri, Jan 22, 2016 at 2:40 PM, Steven Jacobs <[email protected]> wrote: > @Taewoo: I tried removing this in my current code review. It seems it might > already have become obsolete as removing it had little affect. Please check > out my code review again and see if I missed something. > Steven > > On Fri, Jan 22, 2016 at 9:40 AM, Taewoo Kim <[email protected]> wrote: > > > @Till: I agree with you. Actually, at that time, AUUID > > serializer/deserializer was already there so I thought we might need to > > handle both cases (two long values / canonical representation) for > > input/output. I couldn't find a way to use two serializer/deserializers > > (canonical representation / two long values) in one type. Still, I don't > > see how it can be done. But, it would be really nice if we can integrate > > them into one. > > > > Best, > > Taewoo > > > > On Fri, Jan 22, 2016 at 8:49 AM, Till Westmann <[email protected]> wrote: > > > > > Hi Taewoo, > > > > > > I’m still a little confused. To me the type tag is about the type of > the > > > value and it is independent of the serialization. I think that the > > > serialization should be orthogonal to the type of the value. I.e. we > can > > > have > > > a) the binary serialization/deserialization that we use internally to > > > ship/store UUIDs in AsterixDB or we can have > > > b) the string serialization/deserialization that is used when parsing > > > external data or printing results. > > > So in the case of UUIDs we have AUUIDSerializerDeserialize for a) and > > code > > > for b) in AUUID.fromString, AUUIDFromStringConstructorDescriptor, > > > AMutableUUID.fromStringToAMuatbleUUID, and AUUIDPrinter. > > > So I think that we should be covered (actually a little but too much > ..) > > > for both cases and it seems to me that we should be able to remove > > > ATypeTag.UUID_STRING without causing damage. > > > > > > Would you agree or is there something I’m missing? > > > > > > Cheers, > > > Till > > > > > > > > > On 21 Jan 2016, at 11:42, Taewoo Kim wrote: > > > > > > One more clarification: I have created UUID_STRING for mainly > Serializer > > - > > >> deserializer issues. Since UUID serializer/deserializer assumes that > two > > >> long values. It was not sufficient to serialize/deserialize a > canonical > > >> string notation. So, when parsing the outside data, UUID_STRING is > used > > to > > >> serialize/deserialize a UUID. And internally, we use UUID, not > > >> UUID_STRING. > > >> > > >> > > >> Best, > > >> Taewoo > > >> > > >> On Thu, Jan 21, 2016 at 11:36 AM, Taewoo Kim <[email protected]> > > wrote: > > >> > > >> I have created UUID_string. > > >>> > > >>> Internally, a UUID is represented as two long values. However, > > generally > > >>> we use a canonical string notation. So, when we parse a UUID, I had > to > > >>> create a type that can represent a canonical form of UUID. So, > > >>> UUID_STRING > > >>> mainly exists for the parsers. > > >>> > > >>> Best, > > >>> Taewoo > > >>> > > >>> On Thu, Jan 21, 2016 at 11:32 AM, Till Westmann <[email protected]> > > >>> wrote: > > >>> > > >>> Hi, > > >>>> > > >>>> who knows > > >>>> a) what the difference between ATypeTag.UUID_STRING and > ATypeTag.UUID > > is > > >>>> and > > >>>> b) why we need both? > > >>>> > > >>>> Cheers, > > >>>> Till > > >>>> > > >>>> > > >>> > > >>> > > >
