Ps - meaningful as in saying the issue is a duplicate field name and echoing the offending name? On Jul 10, 2015 4:46 PM, "Mike Carey" <[email protected]> wrote:
> Maybe it'd be okay to get a meaningful error message in that unlikely but > indeed possible case? > On Jul 9, 2015 11:59 PM, "Ildar Absalyamov" <[email protected]> > wrote: > >> Sorry, I dropped the ball regarding this thread due to the trip to >> Seattle and first weeks at MSR. >> >> Now when I am mostly done with type system changes, required for this >> issue, I finally gave a look whether the ambiguity is resolved in current >> master, and the answer it is not :) >> The following AQL will fail due to generated type names collision: >> >> use dataverse test; >> create type FooType as open { >> "b": { "c" : { "d": string }}, >> "c_in_Field_b": { "d": int } >> } >> >> If I got Till’s comments correctly nothing prevents JSON identifiers to >> have double quote characters in them if they are escaped, i.e. field with >> name “foo\”bar” is absolutely legal, but by the time it will get though >> parser it will become “foo”bar”, right? >> Can we carry the escaped field name as is and use it for typename >> generation? >> >> > On Jun 25, 2015, at 23:42, Mike Carey <[email protected]> wrote: >> > >> > I don't see any technical reason to disallow characters in the escaped >> case. >> > That being said, we don't have to pick (for our internal names) things >> that we'd >> > prefer not to see being done. :-) I have mixed feelings on the .'s >> for generated >> > type names - as it's not like users will need to use those names for >> anything (as >> > they are internal).... >> > >> > On 6/24/15 6:27 PM, Till Westmann wrote: >> >>> On Jun 24, 2015, at 3:16 PM, Steven Jacobs <[email protected]> wrote: >> >>> >> >>> 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". >> >>> >> >>> This is allowed right now. You would have to access the first as >> "a.b" and >> >>> the second as a.b. The quotes basically tell the parser "this is a >> single >> >>> name with whatever characters I want in it.” >> >> a.b is mainly a convenient shortcut for “a”.”b" >> >> >> >>> To me it seems fine to >> >>> disallow some characters, but back when I had discussions about this >> with >> >>> Vinayak, Mike, and Till, Till was arguing against disallowing >> characters. I >> >>> can't really remember his reasons now though. >> >>> >> >>> @Till, what are your thoughts on this? >> >> All characters are allowed for field names in JSON (http://json.org < >> http://json.org/>). >> >> So if disallow some characters, we will need to map names that contain >> them so something else (or not allow such JSON documents). >> >> It seems that that will get messy and/or painful pretty quickly. >> >> >> >> Cheers, >> >> Till >> >> >> >>> On Wed, Jun 24, 2015 at 11:56 AM, abdullah alamoudi < >> [email protected]> >> >>> wrote: >> >>> >> >>>> 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. >> >>>> >> >> >> > >> >> Best regards, >> Ildar >> >>
