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 + “_” + fieldName, i.e. “Field_address_in_FacebookUserType” is changed to “FacebookUserType_address” 2) Anonymous collection item naming scheme stays the same, i.e. “Field_employment_in_FacebookUserType_ItemType” is changed to “FacebookUserType_employment_ItemType” (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. “Type_#1_UnionType_Field_end-date_in_Field_employment_in_FacebookUserType_ItemType” is changed to “FacebookUserType_employment_ItemType_end-date”, where the type metadata will have an additional field “Optional” with value “true”.
> On Jun 19, 2015, at 18:11, Ildar Absalyamov <[email protected]> wrote: > > 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. > > 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? > >> On Jun 19, 2015, at 13:01, Ildar Absalyamov <[email protected] >> <mailto:[email protected]>> wrote: >> >> 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 >> >> 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 >> >> 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 >> “Type_#1_UnionType_Field_end-date_in_Field_employment_in_FacebookUserType_ItemType" >> in the given example. >> >> 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: >> >> 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 >> } >> >> And here are couple of fields names, generated for it :) >> Type_#1_UnionType_Field_Record_in_Type_#1_UnionType_Field_Derived_in_DatatypeRecordType >> Field_UnorderedList_in_Type_#1_UnionType_Field_Derived_in_DatatypeRecordType >> Field_Fields_in_Type_#1_UnionType_Field_Record_in_Type_#1_UnionType_Field_Derived_in_DatatypeRecordType_ItemType >> >> Best regards, >> Ildar >> > > Best regards, > Ildar > Best regards, Ildar
