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.
