If that's the case, then I think we need to disallow using the "." since it is used to access nested fields and can definitely cause ambiguity.
a clear case is where there is a data type with a field named "a.b" and another field named "a" which has a nested field named "b". Thoughts? On Wed, Jun 24, 2015 at 9:51 PM, Steven Jacobs <[email protected]> wrote: > I think there is no completely user-friendly way around this. Basically our > names allow ALL characters if they are incapsulated in quotes, so there > isn't a character we can use that doesn't have the potential for ambiguity > from the user's perspective. This is why I had to change the nested stuff > in indexing to be a list of strings rather than a single string. > Steven > > On Wed, Jun 24, 2015 at 11:43 AM, Chen Li <[email protected]> wrote: > > > In this case, there could be ambiguity in the names. Does it matter? > > > > Chen > > > > On Wed, Jun 24, 2015 at 11:17 AM, Steven Jacobs <[email protected]> > wrote: > > > > > Fieldnames do allow these characters (both of them). > > > Steven > > > > > > On Wed, Jun 24, 2015 at 11:15 AM, Chen Li <[email protected]> wrote: > > > > > > > I also prefer "." than "_". Also want to confirm that field names > > don't > > > > allow these two characters. > > > > > > > > Chen > > > > > > > > On Wed, Jun 24, 2015 at 10:52 AM, Steven Jacobs <[email protected]> > > > wrote: > > > > > > > > > I second Young-Seek (especially since this is the syntax that users > > > will > > > > > use themselves for nested information in queries). > > > > > > > > > > Steven > > > > > > > > > > On Wed, Jun 24, 2015 at 10:40 AM, Young-Seok Kim < > [email protected]> > > > > > wrote: > > > > > > > > > > > It seems better to use "." instead of "_" since "." is more > > intuitive > > > > (at > > > > > > least to me) than "_". > > > > > > For example, the FacebookUserType_address will be > > > > > FacebookUserType.address. > > > > > > > > > > > > Best, > > > > > > Young-Seok > > > > > > > > > > > > On Wed, Jun 24, 2015 at 6:31 AM, Mike Carey <[email protected]> > > > wrote: > > > > > > > > > > > > > Much cleaner! Others should weigh in here to help finalize the > > > > > > > conventions.... Thoughts? > > > > > > > On Jun 23, 2015 5:31 PM, "Ildar Absalyamov" < > [email protected] > > > > > > > > wrote: > > > > > > > > > > > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Amoudi, Abdullah.
