asterixdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steven Jacobs <sjaco...@ucr.edu>
Subject Re: ATypeTag.UUID_STRING vs ATypeTag.UUID
Date Fri, 22 Jan 2016 22:40:19 GMT
@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 <wangsaeu@gmail.com> 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 <tillw@apache.org> 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 <wangsaeu@gmail.com>
> 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 <tillw@apache.org>
> >>> wrote:
> >>>
> >>> Hi,
> >>>>
> >>>> who knows
> >>>> a) what the difference between ATypeTag.UUID_STRING and ATypeTag.UUID
> is
> >>>> and
> >>>> b) why we need both?
> >>>>
> >>>> Cheers,
> >>>> Till
> >>>>
> >>>>
> >>>
> >>>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message