You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@asterixdb.apache.org by Till Westmann <ti...@apache.org> on 2016/01/21 20:32:46 UTC
ATypeTag.UUID_STRING vs ATypeTag.UUID
Hi,
who knows
a) what the difference between ATypeTag.UUID_STRING and ATypeTag.UUID is and
b) why we need both?
Cheers,
Till
Re: ATypeTag.UUID_STRING vs ATypeTag.UUID
Posted by Taewoo Kim <wa...@gmail.com>.
Good. I will look at it.
Best,
Taewoo
On Fri, Jan 22, 2016 at 2:40 PM, Steven Jacobs <sj...@ucr.edu> 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 <wa...@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 <ti...@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 <wa...@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 <ti...@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
> > >>>>
> > >>>>
> > >>>
> > >>>
> >
>
Re: ATypeTag.UUID_STRING vs ATypeTag.UUID
Posted by Steven Jacobs <sj...@ucr.edu>.
@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 <wa...@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 <ti...@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 <wa...@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 <ti...@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
> >>>>
> >>>>
> >>>
> >>>
>
Re: ATypeTag.UUID_STRING vs ATypeTag.UUID
Posted by Taewoo Kim <wa...@gmail.com>.
@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 <ti...@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 <wa...@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 <ti...@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
>>>>
>>>>
>>>
>>>
Re: ATypeTag.UUID_STRING vs ATypeTag.UUID
Posted by Till Westmann <ti...@apache.org>.
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 <wa...@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 <ti...@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
>>>
>>
>>
Re: ATypeTag.UUID_STRING vs ATypeTag.UUID
Posted by Taewoo Kim <wa...@gmail.com>.
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 <wa...@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 <ti...@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
>>
>
>
Re: ATypeTag.UUID_STRING vs ATypeTag.UUID
Posted by Taewoo Kim <wa...@gmail.com>.
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 <ti...@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
>