Without escaping the name . probably won't parse...?
On 6/24/15 11:43 AM, Chen Li 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
