Mailing-List: contact dev-help@asterixdb.incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@asterixdb.incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of ty13r.derden@gmail.com
 designates 209.85.192.169 as permitted sender)
From: Ildar Absalyamov <iabsa001@cs.ucr.edu>
Content-Type: multipart/alternative;
 boundary="Apple-Mail=_FC0BF428-4F44-49D6-880B-DDCC622A63DA"
Message-Id: <EFAB954A-E9B4-4861-971E-3D191C5428C8@cs.ucr.edu>
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
Subject: Re: Metadata names generation
Date: Tue, 23 Jun 2015 17:29:49 -0700
References: <308FDBD8-616C-4649-8824-C150B794D5F6@cs.ucr.edu>
 <56C5E538-F605-4AC3-B3AB-C05686B8DF44@cs.ucr.edu>
To: dev@asterixdb.incubator.apache.org
In-Reply-To: <56C5E538-F605-4AC3-B3AB-C05686B8DF44@cs.ucr.edu>

--Apple-Mail=_FC0BF428-4F44-49D6-880B-DDCC622A63DA
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

So the general solution is that the generated names should become less =
verbose (consider previous examples):
1) Anonymous fields naming scheme will change to outerTypeName + =E2=80=9C=
_=E2=80=9D + fieldName, i.e. =E2=80=9CField_address_in_FacebookUserType=E2=
=80=9D is changed to =E2=80=9CFacebookUserType_address=E2=80=9D
2) Anonymous collection item naming scheme stays the same, i.e. =
=E2=80=9CField_employment_in_FacebookUserType_ItemType=E2=80=9D is =
changed to =E2=80=9CFacebookUserType_employment_ItemType=E2=80=9D (name =
is changed because the anonymous field employment naming was changed as =
described earlier)
3) Union type completely seizes to exist in metadata (it stays in the =
object model though), i.e. =
=E2=80=9CType_#1_UnionType_Field_end-date_in_Field_employment_in_FacebookU=
serType_ItemType=E2=80=9D is changed to =
=E2=80=9CFacebookUserType_employment_ItemType_end-date=E2=80=9D, where =
the type metadata will have an additional field =E2=80=9COptional=E2=80=9D=
 with value =E2=80=9Ctrue=E2=80=9D.

> On Jun 19, 2015, at 18:11, Ildar Absalyamov <iabsa001@cs.ucr.edu> =
wrote:
>=20
> So I have done half of the fix, which is moved name generation logic =
out of the Metadata node to the client.
> Up to that point nothing in Metadata format was changed, which makes =
me wonder whether I should proceed with the following changes.
>=20
> As it could be seen from the previous email getting rid of =
union-inferred name generation would make auto generated type names less =
scary, but not entirely.
> Having in mind what Mike mentioned earlier today, should we do =
something about other auto generated type name cases?=20
>=20
>> On Jun 19, 2015, at 13:01, Ildar Absalyamov <iabsa001@cs.ucr.edu =
<mailto:iabsa001@cs.ucr.edu>> wrote:
>>=20
>> Currently we are generating the names for inner\anonymous types in =
the following cases:
>> 1) Anonymous field in the record.
>> AQL Example:
>> create type FacebookUserType as closed {
>>         id: int32,
>>         name: string,
>>         address: {
>>         	address_line: string,
>>         	city: string
>> 		state: string
>> 	}
>>     }
>> The pattern for generating an anonymous field name is "Field_" + =
fieldName + "_in_" + outerTypeName, which translates to =
"Field_address_in_FacebookUserType" in the given example
>>=20
>> 2) Anonymous collection (ordered\unordered list) item
>> create type FacebookUserType as closed {
>>         id: int32,
>>         name: string,
>>         employment: [{
>>         	organization-name: string,
>>         	start-date: date
>> 		end-date: date?
>> 	}]
>>     }
>> The pattern for generating an anonymous collection item name is =
collectionFieldName+_ItemType", which translates to =
"Field_employment_in_FacebookUserType_ItemType" in the given example
>>=20
>> 3) Nullable fields
>> Same example as above could be used (end-date field): the pattern for =
generating a nullable field name is "Type_#" + fieldsNumberInUnoinList + =
"_UnionType_" + outerTypeName, which translates to =
=E2=80=9CType_#1_UnionType_Field_end-date_in_Field_employment_in_FacebookU=
serType_ItemType" in the given example.
>>=20
>> So you can see these auto generated names could stack up pretty fast =
and be completely incomprehensible. Just to give you a small flavor of =
that, here is one of the metadata datasets type definitions:
>>=20
>> open {
>>   DataverseName: STRING,
>>   DatatypeName: STRING,
>>   Derived: UNION(NULL, open {
>>       Tag: STRING,
>>       IsAnonymous: BOOLEAN,
>>       EnumValues: UNION(NULL, [ STRING ]),
>>       Record: UNION(NULL, open {
>>           IsOpen: BOOLEAN,
>>           Fields: [ open {
>>               FieldName: STRING,
>>               FieldType: STRING
>>             }
>>           ]
>>         }
>>       ),
>>       Union: UNION(NULL, [ STRING ]),
>>       UnorderedList: UNION(NULL, STRING),
>>       OrderedList: UNION(NULL, STRING)
>>     }
>>   ),
>>   Timestamp: STRING
>> }=20
>>=20
>> And here are couple of fields names, generated for it :)
>> =
Type_#1_UnionType_Field_Record_in_Type_#1_UnionType_Field_Derived_in_Datat=
ypeRecordType
>> =
Field_UnorderedList_in_Type_#1_UnionType_Field_Derived_in_DatatypeRecordTy=
pe
>> =
Field_Fields_in_Type_#1_UnionType_Field_Record_in_Type_#1_UnionType_Field_=
Derived_in_DatatypeRecordType_ItemType
>>=20
>> Best regards,
>> Ildar
>>=20
>=20
> Best regards,
> Ildar
>=20

Best regards,
Ildar


--Apple-Mail=_FC0BF428-4F44-49D6-880B-DDCC622A63DA--